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