Dne 14.3.2013 09:57, Pierre-Yves Chibon napsal(a):
On Thu, 2013-03-14 at 09:46 +0100, Vít Ondruch wrote:
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.
I respectfully disagree here, shared spec is a reality, lots of
packagers use it, I do.
And yes, there is one new entry in the changelog of the F19 branch, is
it a big deal to merge this change into others? I don't think so. In
theory I agree with you, if we really wanted that the changelog reflect
the evolution of the spec per branch, but that does mean that I have 5
potentially different spec files to maintain instead of one and then
merge the changes back to the other branch.
Yes, merge the chances back is wrong. That is the point. Mass rebuild of
F19 never happened on F18 branch. Although you make your life easier,
the output is definitely incorrect and should not be allowed!
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.
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
Vít
--
packaging mailing list
packaging@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/packaging
