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

[Vít Ondruch]

Dne 13.3.2013 18:01, Ralf Corsepius napsal(a):
> 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.

Wrong, if the guidelines would be version specific, it would be obvious 
that you can start using this functionality for F18. Yes, you can hit 
issues if you try on F17, but it was never intended to work on older 
releases, so that is not surprise.

>
> 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).

Yes, testing is definitely needed, but it has nothing to do with f17 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.

There is never too late. For Ruby for example, it means to test 3 
packages at most. This will make no harm even in the middle of F19 
lifecycle.

> Try to propose this as a feature for f20.

Actually this is not bad idea, thank you for suggestion.

>
>
>>> = %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

Yes, we both know that, but it does not help anything as well, so why it 
should be there? It is just bloat.

> => 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?

I shown in other thread that the "shared" .spec is not reality. Now even 
spec for F18 and F19 differs even if you did not touch them, since there 
was mass rebuild and spec has different revisions and changelog entries.

>
>>> = 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.

Copy/paste mistake? :) Should I copy/paste my answer as well? ;)

>
>
>>> 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.

Yes there is no, that is why this thread started. Limited sharing => 
greater innovation of our packaging => less work for new packages as 
well as less learning for newcoming packagers, less possibility for error.


Vít