Allow package variants with different metadata

[JDemler]

This changes allows different package metadata variants. Our use-case are test and live configurations where assets, conf_files and maintainer_scripts may be different.

The variant name is added to the package name: package-name_variant-name_version-string

Variants can be defined inside Cargo.toml in the package.metadata.deb_variant map.

Packaging a variant is as simple as cargo deb --variant <VariantName>

[JDemler]

Actually, deb-packages are not allowed to have underscores in their name. So package-naming is now changed to package-name-variant-name_version-string

[janekolszak]

+1

[kornelski]

Thanks for the PR.

Unfortunately, I don't get what this is for. Can you give more background on this and describe use-cases?

[JDemler]

Imagine you have a package that you want to distribute to a test and a production system. The package for the test system may have different dependencies, different configs or different maintainer scripts.

In our use-case the nginx-config we ship with the package is different for test and production version.

This PR allows for an easy solution to package the same software with different assets, configs, scripts.

[messense]

So I think this should make it possible to produce stripped binaries variant (example.deb) and not-stripped(with debug symbols) variant (example-dbg.deb)?

[JDemler]

Yes, that would be possible as well: cargo deb for example.deb and cargo deb --variant dbg --no-strip for example-dbg.deb

[kornelski]

Test/prod and debug/stripped versions sound like quite useful use-cases indeed.

The proposed implementation uses completely separate metadata for each variant. I suppose many fields would be the same for most variants (especially the debug one). So perhaps instead of replacement, it should be implemented by "patching" of standard metadata with metadata from a variant?

[package.metadata.deb]
maintainer = "Alice <alice@example.com>"
profile = "release"

[package.metadata.'deb(variant = debug)']
strip = false
profile = "debug"

Gives:

maintainer = "Alice <alice@example.com>"
strip = false
profile = "debug"

for --variant=debug

[JDemler]

Yes, that seems like a much better solution. I'll try to have this implemented by the end of the week.

[JDemler]

Config-patching with a basic test-case is now implemented. But rather than using [package.metadata.'deb(variant = debug)']

the config is expecting [package.metadata.deb.variants.debug]

This is both simpler to implement and easier to understand. Also, both strip and profile inside a CargoDeb configuration would be useless atm as strip is set as:

strip: self.profile.as_ref().and_then(|p|p.release.as_ref())
                .and_then(|r|r.debug).map(|debug|!debug).unwrap_or(true),

The possibility of strip and profile inside CargoDeb should be implemented in a different PR IMO.

On a completely different note: Would you accept a cargo fmt pull request? I spent way to much time reverting changes from accidentally running cargo fmt.

[kornelski]

Thank you for the pr. That syntax is fine too.

I've committed some reformatting in f4bb84b135634a4e37fa15e96b24ac31dd27471c, but I find too many things rustfmt does objectionable to apply it unconditionally.