Here is the latest set of changes to the Fedora Packaging Guidelines:
---
A bundling exception for boost within Passenger was granted, due to the intrusive nature of the forked changes, the efforts of the maintainer to merge as many of them as possible into the upstream boost source tree, and the visible efforts of the upstream to keep the bundled copy of boost in sync with the current boost releases.
The package must also include a Requires: bundled(boost) = $VERSION where $VERSION is the boost version being bundled.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant...
---
Packages which have SysV initscripts that contain 'non-standard service commands' (commands besides start, stop, reload, restart, or try-restart) must convert those commands into standalone helper scripts. Systemd does not support non-standard unit commands.
https://fedoraproject.org/wiki/Packaging:Systemd#Unit_Files
---
A section was added to the systemd Packaging Guidelines page with a link to the Tmpfiles.d Packaging Guidelines page, since systemd uses Tmpfiles.d.
https://fedoraproject.org/wiki/Packaging:Systemd#Tmpfiles.d
---
The Ruby Packaging Guidelines were almost completely rewritten. If you maintain ruby packages in Fedora, we advise that you review the new guidelines.
https://fedoraproject.org/wiki/Packaging:Ruby
---
An informational note about Software Collection macros in Fedora Packages was added:
https://fedoraproject.org/wiki/Packaging:Guidelines#Software_Collection_Macr...
---
The guidelines relating to PIE and Hardened Packages were updated. Now, if your package meets the following critera you MUST enable the PIE compiler flags:
* Your package is long running. This means it's likely to be started and keep running until the machine is rebooted, not start on demand and quit on idle.
* Your package has suid binaries, or binaries with capabilities.
* Your package runs as root.
https://fedoraproject.org/wiki/Packaging:Guidelines#PIE
---
Rules involving appropriate scripting within Fedora Package spec files were added to the Guidelines:
https://fedoraproject.org/wiki/Packaging:Guidelines#Scripting_inside_of_spec...
---
The section in the systemd guidelines covering EnvironmentFiles and support for /etc/sysconfig files was revised for clarification.
https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFiles_and_suppor...
---
The Ada Packaging Guidelines were updated for new rules on packaging source files and updated macros.
https://fedoraproject.org/wiki/Packaging:Ada
---
The section of the Packaging Guidelines describing the "bootstrapping" binary exception was amended for clarification:
https://fedoraproject.org/wiki/Packaging:Guidelines#Exceptions
---
The section of the Packaging Guidelines describing Duplication of system libraries was amended to clarify the exceptions for Javascript and parallel stacks.
https://fedoraproject.org/wiki/Packaging:Guidelines#Duplication_of_system_li...
---
These guidelines (and changes) were approved by the Fedora Packaging Committee (FPC).
Many thanks to Kevin Fenzi, Bohuslav Kabrda, Brett Lentz, Marcela Mašláňová, Bill Nottingham, Vít Ondruch, Mamoru Tasaka, and all of the members of the FPC, for assisting in drafting, refining, and passing these guidelines.
As a reminder: The Fedora Packaging Guidelines are living documents! If you find something missing, incorrect, or in need of revision, you can suggest a draft change. The procedure for this is documented here: https://fedoraproject.org/wiki/Packaging/Committee#GuidelineChangeProcedure
Thanks,
~tom
Tom Callaway tcallawa@redhat.com writes:
Here is the latest set of changes to the Fedora Packaging Guidelines:
Packages which have SysV initscripts that contain 'non-standard service commands' (commands besides start, stop, reload, restart, or try-restart) must convert those commands into standalone helper scripts. Systemd does not support non-standard unit commands.
I was a bit surprised to read this, because in recent versions systemd's service command supports nonstandard verbs just fine; it'll pass an unrecognized verb through to the initscript, if there is one. Is that functionality going to be removed again?
Background: after having done what the above text directs me to, I had gotten beaten up over the fact that "service postgresql initdb" no longer worked, and hence reinstituted a stub initscript that only handles the nonstandard actions of the old one. Which works fine, or at least it did as of last month when I last tried it. So now I'm in violation of the guidelines for having tried to keep my users happy, and I'm not happy, especially since the stated rationale is a falsehood.
regards, tom lane
Tom Lane (tgl@redhat.com) said:
Tom Callaway tcallawa@redhat.com writes:
Here is the latest set of changes to the Fedora Packaging Guidelines:
Packages which have SysV initscripts that contain 'non-standard service commands' (commands besides start, stop, reload, restart, or try-restart) must convert those commands into standalone helper scripts. Systemd does not support non-standard unit commands.
I was a bit surprised to read this, because in recent versions systemd's service command supports nonstandard verbs just fine; it'll pass an unrecognized verb through to the initscript, if there is one. Is that functionality going to be removed again?
Background: after having done what the above text directs me to, I had gotten beaten up over the fact that "service postgresql initdb" no longer worked, and hence reinstituted a stub initscript that only handles the nonstandard actions of the old one. Which works fine, or at least it did as of last month when I last tried it. So now I'm in violation of the guidelines for having tried to keep my users happy, and I'm not happy, especially since the stated rationale is a falsehood.
If you're asking if that bit of /sbin/service is going to be removed (redirection to /etc/init.d/<foo> for nonstandard commands), no.
Bill
On 04/12/2012 05:19 PM, Tom Lane wrote:
Background: after having done what the above text directs me to, I had gotten beaten up over the fact that "service postgresql initdb" no longer worked, and hence reinstituted a stub initscript that only handles the nonstandard actions of the old one. Which works fine, or at least it did as of last month when I last tried it. So now I'm in violation of the guidelines for having tried to keep my users happy, and I'm not happy, especially since the stated rationale is a falsehood.
systemd doesn't understand non-standard commands. "service" passes through, but that was determined to be confusing.
If you want to make an initscript stub, you can, but it needs to be in a separate subpackage, per the guidelines. We're trying not to have unit files and sysv initscripts in the same package, whether they're stubs or not.
~tom
== Fedora Project
Tom Callaway tcallawa@redhat.com writes:
On 04/12/2012 05:19 PM, Tom Lane wrote:
Background: after having done what the above text directs me to, I had gotten beaten up over the fact that "service postgresql initdb" no longer worked, and hence reinstituted a stub initscript that only handles the nonstandard actions of the old one. Which works fine, or at least it did as of last month when I last tried it. So now I'm in violation of the guidelines for having tried to keep my users happy, and I'm not happy, especially since the stated rationale is a falsehood.
systemd doesn't understand non-standard commands. "service" passes through, but that was determined to be confusing.
If you want to make an initscript stub, you can, but it needs to be in a separate subpackage, per the guidelines. We're trying not to have unit files and sysv initscripts in the same package, whether they're stubs or not.
Well, if it has to be in a new subpackage then I'm just going to drop it. The entire rationale for the stub was to make things "just work" for people who don't read the release notes. If it requires they install a new subpackage they never heard of before, that would still require reading the release notes, so it's not helpful. (Unless I was to make postgresql-server require the new subpackage, but I'm sure that would not be considered good packaging practice either ...)
regards, tom lane
On 04/13/2012 10:58 AM, Tom Lane wrote:
Well, if it has to be in a new subpackage then I'm just going to drop it. The entire rationale for the stub was to make things "just work" for people who don't read the release notes. If it requires they install a new subpackage they never heard of before, that would still require reading the release notes, so it's not helpful. (Unless I was to make postgresql-server require the new subpackage, but I'm sure that would not be considered good packaging practice either ...)
I understand what you're saying here. I think dropping the stub is the best path forward here, along with making sure that the new "helper" commands are in the release notes.
~tom
== Fedora Project
Tom Callaway (tcallawa@redhat.com) said:
On 04/13/2012 10:58 AM, Tom Lane wrote:
Well, if it has to be in a new subpackage then I'm just going to drop it. The entire rationale for the stub was to make things "just work" for people who don't read the release notes. If it requires they install a new subpackage they never heard of before, that would still require reading the release notes, so it's not helpful. (Unless I was to make postgresql-server require the new subpackage, but I'm sure that would not be considered good packaging practice either ...)
I understand what you're saying here. I think dropping the stub is the best path forward here, along with making sure that the new "helper" commands are in the release notes.
My concern would be that we should likely standardize on a format/invocation for new helper commands wherever possible. Do we have existing ones outside of iptables at this point?
Bill
On 04/13/2012 11:33 AM, Bill Nottingham wrote:
Tom Callaway (tcallawa@redhat.com) said:
On 04/13/2012 10:58 AM, Tom Lane wrote:
Well, if it has to be in a new subpackage then I'm just going to drop it. The entire rationale for the stub was to make things "just work" for people who don't read the release notes. If it requires they install a new subpackage they never heard of before, that would still require reading the release notes, so it's not helpful. (Unless I was to make postgresql-server require the new subpackage, but I'm sure that would not be considered good packaging practice either ...)
I understand what you're saying here. I think dropping the stub is the best path forward here, along with making sure that the new "helper" commands are in the release notes.
My concern would be that we should likely standardize on a format/invocation for new helper commands wherever possible. Do we have existing ones outside of iptables at this point?
We attempted to do this at the same time, but we couldn't come up with anything sane or obvious. If you can, we'd welcome it.
~tom
== Fedora Project
Bill Nottingham notting@redhat.com writes:
Tom Callaway (tcallawa@redhat.com) said:
I understand what you're saying here. I think dropping the stub is the best path forward here, along with making sure that the new "helper" commands are in the release notes.
My concern would be that we should likely standardize on a format/invocation for new helper commands wherever possible. Do we have existing ones outside of iptables at this point?
Postgresql has been using a "postgresql-setup" helper script since F16, and the F16 release notes explain that instead of "service postgresql foo" you should do "postgresql-setup foo". The two nonstandard actions provided this way are "initdb" and "upgrade", both of which are for database setup, hence the choice of script name. That choice probably doesn't fit for other uses of nonstandard actions, though.
regards, tom lane
On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote:
A bundling exception for boost within Passenger was granted, due to the intrusive nature of the forked changes, the efforts of the maintainer to merge as many of them as possible into the upstream boost source tree, and the visible efforts of the upstream to keep the bundled copy of boost in sync with the current boost releases.
The package must also include a Requires: bundled(boost) = $VERSION where $VERSION is the boost version being bundled.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant ed_exceptions
While I appreciate the work Brett Lentz has been putting in upstream, why does this package have to be taken away from me?
I'm already facing a "thanks for your work but no thanks"[1].
I respectfully request Uncle Shadowman *not* be forcefully made the owner of the package, and the reporter of the review request be granted ownership.
Kind regards,
Jeroen van Meeuwen
[1] https://bugzilla.redhat.com/show_bug.cgi?id=470696#c114
On 04/14/2012 02:32 PM, Jeroen van Meeuwen wrote:
On Thursday, April 12, 2012 04:57:29 PM Tom Callaway wrote:
A bundling exception for boost within Passenger was granted, due to the intrusive nature of the forked changes, the efforts of the maintainer to merge as many of them as possible into the upstream boost source tree, and the visible efforts of the upstream to keep the bundled copy of boost in sync with the current boost releases.
The package must also include a Requires: bundled(boost) = $VERSION where $VERSION is the boost version being bundled.
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Packages_grant ed_exceptions
While I appreciate the work Brett Lentz has been putting in upstream, why does this package have to be taken away from me?
I'm already facing a "thanks for your work but no thanks"[1].
I respectfully request Uncle Shadowman *not* be forcefully made the owner of the package, and the reporter of the review request be granted ownership.
Kind regards,
Jeroen van Meeuwen
No need for this to be mutually exclusive, unless one (or both) of you are averse to being comaintainers?
-- rex
On Saturday, April 14, 2012 03:11:46 PM Rex Dieter wrote:
No need for this to be mutually exclusive, unless one (or both) of you are averse to being comaintainers?
I'm objecting based on the matters of principle and due process.
Kind regards,
Jeroen van Meeuwen
On 04/12/2012 08:57 PM, Tom Callaway wrote:
The section in the systemd guidelines covering EnvironmentFiles and support for /etc/sysconfig files was revised for clarification.
https://fedoraproject.org/wiki/Packaging:Systemd#EnvironmentFiles_and_suppor...
Just for the record it's not just systemd upstream that frowns upon the usage of /etc/sysconfig/foo files but also upstream in general due to the location of those environment files as in the /etc/sysconfig directory which is Fedora/Red Hat specific.
Upstream has refused to included systemd units that contained reference to /etc/sysconfig/foo environment files understandably so since those units aren't distribution agnostic.
What that means for us that in the long run we are going against our own upstream mantra and we will need to start carrying our own patches which adds this behavior.
There are two ways we can solve this.
A)
Get rid of usage of /etc/sysconfig/foo environment files on units since they really aren't necessary anymore and activily advocate copying and edit or create a unit file with .include reference in /etc/systemd/system directory.
Or
B).
Adjust that packaging guidelines so those environment files are either stored directly under /etc or under it's own directory under /etc.
Note that the removal of /etc/sysconfig environmental files has been meet with little to no resistance within the project from maintainers that either are upstream or are actively involved with upstream.
It would have been good to see the guidelines adjusted to have package dropping the legacy sysv init script altogether once the relevant service/daemon has been migrated to native systemd support since it's serves absolutely no purpose shipping the legacy sysv init script in a sub package.
JBG
packaging@lists.fedoraproject.org
-
Bill Nottingham -
Jeroen van Meeuwen -
Jóhann B. Guðmundsson -
Rex Dieter -
Tom Callaway -
Tom Lane