[Proposal] Packaging guidelines/spec per version

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging



[Index of Archives]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite Forum]     [KDE Users]

  Powered by Linux