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

[Pierre-Yves Chibon]

On Thu, 2013-03-14 at 09:57 +0100, Pierre-Yves Chibon wrote:
> On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
> > >>> 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.

One point which I forgot here, there is the question of the review.
If we go for different spec for different branches, that means that
before starting the review the branches that will be requested should be
known and that eventually, the submitter needs to provide multiple spec,
one per branch of interest.

Pierre