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. > 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. > 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. > > 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. > 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. 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. > 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. > > 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. -- Nicolas Mailhot
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
