Add support for setting RPMTAG_FILECAPS header

[dsteeley]

This change adds support for setting the RPMTAG_FILECAPS header to add capabilities to the files packaged in the rpm.

📜 Checklist

• [x] Commits are cleanly separated and have useful messages
• [x] A changelog entry or entries has been added to CHANGELOG.md
• [x] Documentation is thorough
• [x] Test coverage is excellent and passes
• [x] Works when tests are run --all-features enabled

[dralley]

It would be great if we could fill out support for reading filecaps also, so that we can write functional tests for this.

https://github.com/rpm-rs/rpm/blob/master/src/rpm/package.rs#L836

[dralley]

I haven't checked the behavior of RPM, but if it doesn't set FILECAPS if none were used in the specfile, we should probably avoid setting that tag if the user didn't provide any as well.

If it always sets the FILECAPS tag, then this is fine.

[dsteeley]

I've got these changes on a separate branch at the moment. Would you like them here with a functional test or kept separate?

My understanding of the behaviour here is that if not present then the header isn't added. I've updated the behaviour to not add the header unless any file has a capability.

[dralley]

Feel free to put it all in one PR, IMO it would be a bit cleaner particularly w/r/t testing. You can keep commits separate if you want.

[dralley]

There are some test failures but apart from that I like the way this looks.

Once that's addressed go ahead and squash it all into one commit (or I can do that when merging it, I suppose)

[dsteeley]

Fixed up the test, my switch to use FileCaps causes the default capability (in the case where the header is added) to be =. Which the following doc indicates as correct behaviour for no capability, https://www.man7.org/linux/man-pages/man3/cap_from_text.3.html. In the case that no files have a capability set the default is still to not add the header.

[dsteeley]

@dralley The failing job is an issue compiling time-macros on rust 1.65. Any preference or suggestion on how I resolve?

[dralley]

The failing job is an issue compiling time-macros on rust 1.65. Any preference or suggestion on how I resolve?

You can just pin time to an older (compatible) version for now.

[dralley]

@dsteeley Are you looking for a release soon or is waiting a few weeks OK?

And just out of curiosity, are you actively using (or considering) this for building RPMs at MS?

[dsteeley]

@dsteeley Are you looking for a release soon or is waiting a few weeks OK?

And just out of curiosity, are you actively using (or considering) this for building RPMs at MS?

Not in a rush, although I'd like to get this plumbed through cargo-generate-rpm at some point.

We are already using this (via cargo-generate-rpm) to package rust binaries as rpms and then containerise using rpmoci. I'd like to have to option to set capabilities on those binaries, currently doing it via post install script which isn't the neatest solution.

[dsteeley]

@dralley Are you planning to squash this or do you want me to combine into one commit?

[dralley]

Nah I got it.

[dralley]

@dsteeley Thanks!