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

[Vít Ondruch]

Dne 13.3.2013 18:31, James Antill napsal(a):
> On Wed, 2013-03-13 at 16:26 +0100, Vít Ondruch wrote:
>> Dne 13.3.2013 16:18, Toshio Kuratomi napsal(a):
>>> On Wed, Mar 13, 2013 at 01:12:00PM +0100, V?t Ondruch wrote:
>>>> 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.
>>>>
>>> This is a non-starter, I'm afraid.
>> Yes, unless you provide any rationale behind your statement, it cannot
>> start even discussion I am afraid. And since you are just afraid, could
>> you please share your fears? May be we can overcome them together.
>   Think of it like having some software that needs to run on FreeBSD and
> Linux ... there are differences, but in the vast majority of cases it's
> going to be better to have a single source than to fork.
>
>   While you could argue that it's "better" to fork more of the time for
> spec. file versions, than in C code, I'd rejoin:
>
> 1. It being better to share as much code as possible, with conditionals
> of the bits you can't share, is accepted wisdom basically everywhere. So
> I'd need a great argument/data/etc. to believe this is not true for
> spec. files.

Not exactly ... it is definitely fine to have for example one file, 
which solves the platform specific bits, included by conditionals then 
to have conditionals scattered all around the code. If the code contains 
conditional all around, it is unreadable and non-maintainable, hopefully 
with exception of original author.

>
> 2. The examples I've seen you give to support your case make me think
> you need to learn how to write better "portable code" (and weren't
> compelling, even though they could be made much better).
>
> 3. I didn't see any evaluation on the downsides of forking all the
> specfiles (something, again, which history/experience would say is
> non-trivial).
>
> 4. Even if it's true and it's only good to share the spec files in 10%
> of cases, banning the use of something that helps 10% of packages
> (~1,000 packages in Fedora) and has no downsides for everyone else is
> not something I'd vote for.

"Ban" something is strong word. I would say encourage, e.g. the 
guidelines would contain "You *should* not share the .spec, because ..."
>
> ...so basically, if you still want to pursue this you'd want to have a
> good argument that:
>
>   i) Shows how having compatibility is bad for specfiles, in spite of all
> historical evidence in related fields.

My initial email in this thread contained examples.

>   ii) Shows how there is no/little downside to forking specfiles, in
> spite of all historical evidence in related fields.

Although the updates in Fedora and EPEL are not prohibited, they are 
definitely not encouraged [1]. Basically, you should limit the updates 
to bug fixes. If you maintain lively package, there is high chance that 
between two releases of Fedora, there was some more significant upstream 
release then just bugfixing release. So at this point, the .spec files 
between Fedora versions *must* differ. As soon as they differs, it is 
good time to give up and update the spec in the master to follow the 
recent development in packaging.

If you want share the .spec file, you probably diverge from the 
suggestion given you by update policy, that you should not update except 
bugfixes, or your package is in clinical death.

Nevertheless, there happens to be mass rebuilds in that case, so your 
.spec file in F19 is going to be different although you did not changed 
anything in it. So again, what is the point now, since you cannot merge 
the branches anymore, with luck, you can cherry-pick the changes and you 
have to always fix the changelogs. Or you gave up and for example your 
F18 branches now contains the same "mass rebuild" changelog entries? 
That seems to be wrong.

>   iii) Shows that there is actual harm in some packages having
> compatibility, even if we'd generally recommend against it after you
> proved i) and ii).
>
> ...also my personal experience is that directly the opposite of i) and
> ii) ... so good luck.
>
>

Vít



[1] http://fedoraproject.org/wiki/Updates_Policy#Philosophy