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