On 03/13/2013 04:20 PM, Vít Ondruch wrote:
Dne 13.3.2013 13:12, Vít Ondruch napsal(a):
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].
-1 Any changes to NEVR conventions are dangerous. They need to be supported by all rpm-related tools and all active versions of Fedora.
I.e. I don't see much sense in allowing tilde before all rpm-related tools in Fedora have been tested for supporting this and before all Fedoras' rpms support it (I.e. not before f17 went EOL).
= 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.
-1 Too late for f19. Try to propose this as a feature for f20.
= %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
-1 %clean doesn't do any harm => No need for action. Can be grandfathered.
= 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.
Because specs might be shared?
= mandatory %defattr at the beginning of %files section
Not needed since RPM 4.4 [8].
-1 %clean doesn't harm => No need for action. Can be grandfathered/ignored.
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.
There is no rule prohibiting maintainers from doing so. It's up to a package's maintainer's discretion.
Ralf