On Sun, 2008-07-13 at 08:55 +0200, Nicolas Mailhot wrote:
> Le samedi 12 juillet 2008 à 15:31 -0400, Doug Ledford a écrit :
> > On Sat, 2008-07-12 at 21:00 +0200, Nicolas Mailhot wrote:
> > > Le samedi 12 juillet 2008 à 14:30 -0400, Doug Ledford a écrit :
> > >
> > > > Even if I thought Panu would take the header changes and any other
> > > > possible things I might do to RPM, if the other people who control these
> > > > other items of Fedora infrastructure are dead set against this type of
> > > > work, then it's a waste of my time to futz around with it unless I'm
> > > > willing to fork my own distro. The responses I've gotten so far have
> > > > not made me inclined to think the powers that be will even look at
> > > > things, but I could be wrong.
> > >
> > > As Jesse Keating tried to tell you, the reality is that the owerwhelming
> > > majority
> >
> > First, before I respond to the rest of this, keep in mind that the
> > "overwhelming majority" of packages needs to be quantified.
>
> How about the 9/10th of packages I've been involved with since I used
> RHL or Fedora (I think I've passed my decade of use and packaging now)?
>
> I'll grant you a few of them are clean SCM dumps. Since I had to rewrite
> upstream's release script myself (and get it merged) to make sure it was
> always the case.
Of the 26 or so packages I currently deal with from the InfiniBand
community, the only difference between the tag in the SCM and the
tarball is the running of autogen.sh and that's only because I *told*
them to do so. Then of course I also deal with the kernel. So, you'll
excuse me for not having the innate perspective you do on this issue.
Everyone I deal with treats their SCM setup sanely.
> > Furthermore, at least one very significant package (the kernel) does not
> > massage files at all between SCM tag and tarball.
>
> If you can't understand the kernel is utterly unrepresentative in so
> many ways that's not even funny I can do nothing for you.
The kernel content is certainly not representative. However, that
doesn't change the fact that it is both a very large project that would
benefit greatly from the changes I'm talking about and also a nice
example of good SCM policies in practice upstream.
> > And to be honest, I
> > would be very surprised to find many projects that do have any
> > significant difference between a tagged release in the SCM of their
> > choice and their tarballs.
>
> It does not need to be huge to cause no end of QA and maintenance
> problems.
>
> > So I would like some examples please, which
> > shouldn't be hard to come up with since it is the "overwhelming
> > majority" of projects that obviously think when they tag something in
> > their SCM it doesn't need to match the tarball they make with the same
> > tag version...
>
> Take ten random packages in the review queue. They need the review and
> you need some perspective.
Actually, I'll take you up on that just to see. Thanks for the
suggestion.
> > > of the code we package is not pure VCS dumps, because upstreams
> > > massage their files manually before doing official releases, so being
> > > able to base a package on a precise tar.gz as posted on upstream's
> > > homepage is a hard requirement.
> >
> > No, it's a *policy* that we base things on a precise tarball on some
> > web/ftp server.
>
> If you haven't noticed yet we are choke-full of policies that could all
> be reverted but contribute to make life easier to packagers.
I'm sorry, but this policy you speak of does not make life easier. And
while they could all be reversed, this one actually deserves to be
reversed.
> > It's a policy that is no better or worse than basing a
> > package on a precise tagged source version in an SCM. And to be honest,
> > I couldn't care less if upstream's tarball and their SCM version match
> > or not. It's not important that they match, it's important that we pick
> > one to be canonical, that we make our choice of which is canonical clear
> > and apparent to everyone, and then we use that source consistently
> > within that package. That's all that matters.
>
> No.
> What matters is we pick the version upstream intends us to use.
And if we tell upstream that we are going to use a particular tag in
their SCM instead of a tarball, upstream can do their preparation there.
Really, this isn't rocket science, it's just letting upstream know what
we are doing and then they are fully capable of working with us on this.
Only if we get so inured in our current way of doing things that we
can't possibly change does this become impossible to correct.
> What matter is we pick the version upstream checked for problems before
> publishing (even if that involved some dirty upstream massaging)
> What matters is we use the same upstream version as everyone else so we
> benefit from the collective QA work the community does.
> What matters is our users know exactly what they get and not dumps of
> VCS soup.
Like I said. Talk to upstream. Issue solved. Colin more or less made
the same point. Assuming upstream won't work with us on something like
this is a totally silly reason not to try.
> > Claiming that a precise
> > tar.gz is a hard requirement is patently fallacious. It's currently a
> > hard requirement *solely* because we haven't integrated cloned SCM repo
> > support in Fedora yet, and since we are talking about implementing
> > exactly that support, it negates this "hard" requirement.
>
> You've certainly lived a sheltered life with no contact with the kind of
> code one can find in the internet.
No, I've been in contact with all sorts of code. Some good, some bad,
some you felt like you needed a bath after looking at. Regardless
though, I've generally found that upstream is willing to work with me on
things. I would expect a change like this to be no different, and I'm
certain that all 26 or so packages I'm working on would gladly implement
the minimum policy requirements I have for their SCMs in order to make
this happen (immutable tags, no deletions only revertions, and I keep a
local clone in case they implode). Of course, I'm spoiled in that all
26 of those packages use git. Guess I'm just a lucky bastard.
> > > As long as your system can take this into account I don't think anyone
> > > would mind having a more modern way to manage the stuff we put around
> > > this upstream archive.
> >
> > Sorry, but if I do the work, then I'm writing it to eliminate the
> > tarball. You don't have to switch your package to this new method if
> > you don't wish, but I'll be switching my packages over and they will
> > never touch a tarball again.
>
> If you don't want to listen, don't complain you're not heard.
I don't want to listen to "It can't be done, so don't try". I don't
care if I'm heard, I care that people don't block me from going my own
way and doing my own thing. To which end, I think I'm done with this
thread. We've beat the horse to death. The people that handle the
Fedora infrastructure will either take the patches or they won't, I'm
headed off to write them.
--
Doug Ledford <dledford@xxxxxxxxxx>
GPG KeyID: CFBFF194
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Attachment:
signature.asc
Description: This is a digitally signed message part
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
