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

[Vít Ondruch]

Dne 14.3.2013 12:27, Pierre-Yves Chibon napsal(a):
> On Thu, 2013-03-14 at 12:11 +0100, Vít Ondruch wrote:
>> Dne 14.3.2013 09:57, Pierre-Yves Chibon napsal(a):
>>>>>>> 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.
>>> I disagree on the less learning for new packagers, if they package
>>> something that they want on the 4/5 branch available, they'll have to go
>>> through each version of the guidelines.
>>> At the moment we have one set of guidelines which mentions:
>>> Note: for EPEL5, you MUST have a %clean section
>>> Note: for EPEL5 the %defattr is mandatorry
>>> ...
>>> If I understand correctly your proposal, to build a package for 4
>>> different branches, I'll have to go through all these branches'
>>> guidelines and find out how they different from devel which is the
>>> mandatory branch.
>> You have to do it anyway, that is the point. Claiming anything else is
>> not true. If there is inline note about exception, it makes it even
>> harder to notice it. You cannot do diff between two guidelines and
>> really see what is different.
> At the moment, there is the main guideline to check and they do mention
> what's specific to EL5/EL6. There are not 5 pages mentioning the
> guidelines to package for that specific branch.

Yes, if you are not speaking about language specific guidelines, where 
it gets interesting.

>
>>> In addition, we are a community of volunteer, I think we have to be
>>> careful on making their life easier rather than harder and to me, not
>>> having the possibility to merge my changes between branches would make
>>> my life harder.
>> Yes, that is definitely intention to do your life easier and with every
>> release of RPM, your life could be easier if you migrate your spec to
>> the latest greatest features RPM provides, but you don't wan't to. I
>> can't help you with that, sorry
> Well, it might make your life easier for one branch, but not overall.
> That's at least my opinion/feeling.
>
> Anyway, we have a difference of opinion here.
> What you find unacceptable I find minor or manageable, you really want
> different spec per branch, I tend to avoid that as much as I can (even
> if I agree, there is a point where having different spec makes sense).
> All I can say is that if you bring this proposal to a wider audience,
> I'm pretty sure there will be a lot of people feeling the same way.

It is managable if you care just about your packages. I care about Ruby 
and hence I care about every other package which depends on Ruby. In 
such case it is unmanagable.

And we are speaking about possible changes in RPM, that might affect all 
packages in Fedora.

But since you do various branches in one .spec file, the .spec file 
becomes un-updatable by script.

> The current system allows each maintainer to use the latest version of
> the guidelines or to maintain one spec consistent across branches if he
> wishes to. I think this is the approach that has the most flexibility
> and changing it will crease some feathers.

As well as non-changing it. If beginer takes a look on some hugely 
conditionalized .spec file, he will screaming escape. .spec file should 
be sort of configuration file, not a script.

Vít