[Fedora-packaging] [Proposal] Packaging guidelines/spec per version

Vít Ondruch vondruch at redhat.com
Wed Mar 13 12:12:00 UTC 2013


Hi,

Wouldn't it be possible to have packaging guidelines versioned by Fedora 
version? If this would be accompanied by the rule, that .spec files 
can't be shared as well (using some conditions), this would allow us to 
have much faster evolution of our packaging. I'll give you a few examples.

= Tilde versioning

It is available in RPM since 4.10 [1], i.e. Fedora 18. It is prohibited 
by guidelines [2].

= Support for /usr/lib/rpm/macros.d/

Available since RPM 4.11 [3, 4], i.e. Fedora 19, nobody place the 
additional macros there (well I'll fix Ruby and RubyGems as soon as I'll 
have some free cycles). Actually it could be nice scripted.

= Changes in Ruby guidelines

There are currently 3 versions of Ruby guidelines [5], which apply to 
different versions of Fedora and EPEL anyway.

= %clean section

Not mandated since F13 [6], but widely used in older packages. That 
could be easily removed by script it there would not be chance that the 
package is in use for EPEL5

= BuildRoot tag

Not needed since F10! [7] But needed by EPEL. BTW you should not update 
packages in EPEL, to keep ABI stability, anyway, so why you should carry 
around such thing in F20? There is high chance that EPEL5 package 
contains much older version.

= mandatory %defattr at the beginning of %files section

Not needed since RPM 4.4 [8].

This is not exhaustive list. If you just count %clean section, BuildRoot 
tag and %deffattr, the spec file could be 5 lines shorter. 5 lines which 
can make difference in maintainability, in attraction new packagers, 
since they would not need to wonder "what the BuildRoot is there for?"

What I have learned during recent rebuild of Ruby packages is that the 
.specs, which contains conditions to support different versions of 
Fedora or EPEL are the one, which are the hardest to maintain. There is 
no simple way how to automatically migrate them to support newer 
guidelines. This exactly prohibits the innovation. This prohibits any 
new feature which we could benefit.

If the .spec would be specific to the Fedora version, it could follow 
the latest and greatest development. However there are some version 
specific branches which prevent that.

Some may object, that the resulting binary RPM should be compatible 
between Fedoras and installable everywhere, but I can assure you, that 
you cannot install any RPM which depends on Ruby from F18 to F19 and 
vice versa, so the argument is moot. This apply also to all libraries 
after soname bump, not just that we are doing something terribly wrong 
in Ruby.

So please, consider this proposal. In a long term (speaking about really 
long term now), the .spec file should contain just a few lines, such as 
SOURCE0 and the rest would be done by a few simple macros. Take a look 
for example what Java guys did recently [9] and how it used to be [10] 
(I am sure they could provide you better examples :). This would let us 
to focus on more important things then copy pasting guidelines to .spec 
files.


Thank you


Vít




[1] http://www.rpm.org/wiki/Releases/4.10.0
[2] http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Version_Tag
[3] http://www.rpm.org/wiki/Releases/4.11.0
[4] https://bugzilla.redhat.com/show_bug.cgi?id=846679
[5] https://fedoraproject.org/wiki/Packaging:Ruby
[6] https://fedoraproject.org/wiki/Packaging:Guidelines#.25clean
[7] https://fedoraproject.org/wiki/Packaging:Guidelines#BuildRoot_tag
[8] https://fedoraproject.org/wiki/Packaging:Guidelines#File_Permissions
[9] https://fedoraproject.org/wiki/Packaging:Java#Apache_Maven
[10] 
https://fedoraproject.org/w/index.php?title=Packaging:Java&oldid=246507#maven2


More information about the packaging mailing list