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

[James Antill]

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.

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.

...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.
 ii) Shows how there is no/little downside to forking specfiles, in
spite of all historical evidence in related fields.
 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.