== Summary ==
redhat-rpm-config will be updated so users of the auto framework get
automated release and changelog bumping.
== Owner ==
* Name: [[User:nim| Nicolas Mailhot]]
* Email: <nicolas.mailhot at laposte.net>
== Detailed Description ==
This is a system-wide change because all packages build with
redhat-rpm-config, but it only concerns packages that opted to use
this part of redhat-rpm-config (auto framework).
The change will make those packages auto-bump and auto-changelog at
the rpm level, in an infrastructure-independent way.
== Benefit to Fedora ==
Autobumping removes a huge packager shore and makes timestamping in
changelogs more reliable.
== Scope ==
* Proposal owners: The feature is coded and works at the rpm level.
Unfortunately, mock filters away the srpms containing the bump state,
so it does not work in upper layers.
* Other developers: The feature requires buy-in by mock developers
(and probably koji developers) to lift the restrictions that block it
above the rpm level. Also, it requires a mechanism to pass the user
name and email that will be used in bumped changelogs (defining two
variables in ~/.rpmmacros is sufficient at rpm level)
* Mock issue: https://github.com/rpm-software-management/mock/issues/599
* Release engineering: https://pagure.io/releng/issue/9567
* Policies and guidelines: maybe eventually if things work out on the
* FPC issue: https://pagure.io/packaging-committee/issue/998
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This is a pure build tooling update, it changes how things are built
not what is built.
== How To Test ==
A redhat-rpm-config packages with the changes and some example
packages are available in
Since the mock/copr layer is currently blocking the feature, you need
to install the redhat-rpm-config and forge macro packages available in
this repo locally. Afterwards you can take any of the example packages
in the repo and rebuild them with rpmbuild -ba to your heart content,
and see the releases bump and the changelogs being updated
To get beautiful changelogs, you also need to add
%buildsys_name Your name
%buildsys_email Your email
== User Experience ==
N/A Packager experience change only
== Dependencies ==
The change is a spin-off of
Therefore, it depends on the success of that other change and will
probably need rebasing if the code in this other change evolves during
the redhat-rpm-config merge.
It also depends on mock / copr/ koji buy-in and changes, that may add
their own requirements.
== Contingency Plan ==
There is no contingency plan because the change will happen or not at all.
== Documentation ==
There is as much documentation as the average redhat-rpm-config change
(ie comments in the macro files themselves)
== Release Notes ==
N/A Packager productivity change only
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
On Wed, Mar 02, 2022 at 07:11:42PM -0500, Steve Grubb wrote:
> On Tuesday, March 1, 2022 6:43:57 PM EST Michel Alexandre Salim wrote:
> > The subject of setuid came up in a private conversation recently, and to my
> > surprise we don't seem to have it documented in the packaging guidelines:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/
> > Per https://fedoraproject.org/wiki/Features/RemoveSETUID#Documentation
> > "We should change documentation on packaging guidelines to talk about
> > using file capabilities."
> > but the only mention of capabilities seem to be that, if you use it or
> > suid, PIE must be enabled:
> > https://docs.fedoraproject.org/en-US/packaging-guidelines/#_pie
> > Should this be documented somewhere, or if it's there but it's lost in
> > the wiki->docs migration, does anyone know where the documentation is?
> As someone involved in that change, the situation was much worse back in
> 2011. Almost everything was running as root. The inspection tools back then
> were non-existent, which is what I wrote pscap and netcap.
> Now, a lot of things use capabilities with a few still running as root when
> they don't need to be. But I have not looked at all daemons. The lesser used
> ones may need checking. But I think maybe some guidance could be good.
> Something like:
That's really comprehensive, thanks. Can we document this? I'm a bit
worried about the situation where a packager and a reviewer don't have
the institutional memory of "we recommend capabilities over
setuid/setgid" and new setuid packages creeping in again.
Michel Alexandre Salim