Recent Features
| |||||||||||||
Packaging and patchingPackaging and patchingPosted Aug 24, 2009 6:17 UTC (Mon) by dgm (subscriber, #49227)In reply to: Packaging and patching by rlk Parent article: On properly packaging perl
This is a serious argument against distro packagers playing developers.
In my opinion, a packager should NEVER, EVER patch something. If it doesn't work, complain to upstream until it's fixed. If it's not fixed, drop the package or revert to a previous version. The case of security fixes is not different. But that's just my opinion, of course.
(Log in to post comments)
Packaging and patching Posted Aug 24, 2009 8:44 UTC (Mon) by Trou.fr (subscriber, #26289) [Link]
and when upstream is not replying ? Not ready to accept any patch ? When some packaging requirements are only met with patches ?
And regarding security issues, i'd rather have a quick patch by the packager than a week late patch by upstream.
Packaging and patching Posted Aug 24, 2009 12:19 UTC (Mon) by dgm (subscriber, #49227) [Link]
Just drop the damn thing. Or find someone to fork it.
A quick fix made by a packager that doesn't understand the implications can create more problems that it solves (Debian OpenSSL anyone?) Also your arguments is based on the *false* assumption that packagers do release fixes faster than upstream. And now that we're at it, instead of just packaging everything under the sun, why not just talk to upstream regarding their stance behind the code _before_ creating a package for it?
Packaging and patching Posted Aug 24, 2009 14:53 UTC (Mon) by foom (subscriber, #14868) [Link] Why? Because I like distros that have everything under the sun, and work as an intermediary between possibly-uncooperative upstreams and me. And who do the work that most upstreams don't do to make the software work together easily and consistently.There have been a couple disastrous changes, indeed, but the vast majority of minor modifications I greatly appreciate having.
Packaging and patching Posted Aug 25, 2009 7:04 UTC (Tue) by dgm (subscriber, #49227) [Link]
I also did like them, back when there was not much OSS software. But it's not 1995 any more, and now we have loads and loads of OSS packages for almost everything.
I tend to think that the 80/20 rule also applies to software (yes, all software), thus much of what is there is crap. A process that sinks crap and lets the good stuff stay afloat is really needed to ensure a sane evolution of the good software. Some distributions (Debian and Ubuntu at least) let this up to the user, in the form of a popularity contest. Wrong. This is _the_ task that the packager should be doing. All those "minor modifications" just make things _unnecessarily_ harder for everybody.
Packaging and patching Posted Aug 25, 2009 15:38 UTC (Tue) by foom (subscriber, #14868) [Link] Well, I like my software modified and configured to work better as a whole. And I like that no matter what software I want (even if you consider it crap), it's almost certainly already available in Debian.There's space in the world for multiple distributions with different goals, and I bet there's at least one which doesn't modify upstream source code that you can use.
Packaging and patching Posted Aug 27, 2009 23:16 UTC (Thu) by branden (subscriber, #7029) [Link]
Your citation of the Debian OpenSSL fiasco is a bullshit example.
As was widely reported at the time, Debian's package maintainer *did* take
There was lots of fail in the Debian OpenSSL situation, but failure to run
Packaging and patching Posted Aug 28, 2009 0:12 UTC (Fri) by rlk (guest, #47505) [Link]
That was my recollection about what happened; thank you for correcting the details.
In the Gutenprint example, nobody ever attempted to contact us (we have a development mailing list that's noted on our web site that's open subscription), even to notify us that they were making the change in question. We were left to find out about it from complaints from unhappy users.
Packaging and patching Posted Aug 29, 2009 20:51 UTC (Sat) by dirtyepic (subscriber, #30178) [Link]
Um, what? Packagers _do_ release fixes faster than upstream. They even release _upstream_ fixes faster than upstream. If they didn't, there wouldn't be a reason to patch in the first place.
I can patch a freetype bug in Gentoo and have it out to users sometime within the next hour (whenever the next rsync mirror update is). I don't think they can make a release that fast. In fact, we patched a security vulnerability in freetype-2.3.9 back in May, and as of now there still hasn't been a new upstream release. So, should we drop freetype or fork it? (note: i don't mean to pick on freetype here, it's just a package i happen to maintain)
And by "release" I mean get the fix out to the people encountering the bug, not fix it in the repo for whenever the next release may be. If you have some other definition then please share it.
We also recently patched fontconfig because recent upstream changes were causing problems with our sandboxed build environment (packages calling fc-cache during `make install` would fail because fc-cache now runs chmod on /var/cache/fontconfig and we don't allow packages to change permissions on files or directories they don't own outside of the DESTDIR during install). I did let upstream know about the issue, but ultimately I fixed it locally because it was our policy causing the issue, not upstream. Debian also modifies most packages to comply with their policies. Expecting upstream to accommodate the (sometimes conflicting) packaging policies of every major distro is ridiculous.
Trust me, we would love it if everything worked the way we wanted out of the box. We don't go through the trouble of maintaining large patchsets for the sheer enjoyment it gives us.
Packaging and patching Posted Aug 24, 2009 15:32 UTC (Mon) by mcopple (guest, #2920) [Link]
It doesn't have to be an either/or proposition.
When downstream discovers the problem, open a bug for it with upstream. If upstream doesn't have it fixed by the time the distributor needs it, fix it yourself, display it prominently in the release notes, notify upstream you've done it.
If upstream still doesn't do anything about the problem, then it is upstream's problem; you keep the patch in place and your customers are satisfied. If upstream resolves the issue to the distributor's satisfaction, use upstream and quietly drop the downstream patch.
Packaging and patching Posted Aug 24, 2009 18:46 UTC (Mon) by nevyn (subscriber, #33129) [Link] Sure, Fedora should just fork python or drop it completely (upstream have refused to take multilib seriously). Not to mention what awesome support you'd get off all upstreams for everything in RHEL-5 atm. You seem to have awesome ideas, do you produce a newsletter I can subscribe to?
|
|||||||||||||