Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
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)
Posted Aug 24, 2009 14:53 UTC (Mon) by foom (subscriber, #14868)
There have been a couple disastrous changes, indeed, but the vast majority of minor modifications I
greatly appreciate having.
Posted Aug 25, 2009 7:04 UTC (Tue) by dgm (subscriber, #49227)
Posted Aug 25, 2009 15:38 UTC (Tue) by foom (subscriber, #14868)
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.
Posted Aug 27, 2009 23:16 UTC (Thu) by branden (subscriber, #7029)
As was widely reported at the time, Debian's package maintainer *did* take
the patch to the documented upstream development list. Communications
took place, but went awry, with each side not completely understanding the
other. Ben Laurie later waded in to cluck that distributors suck, and
that the patch should have been sent to the list that all the cool OpenSSL
upstream kids read. (The existence of said list was a well-kept secret
from the general public until the bug in question blew up in Debian's
There was lots of fail in the Debian OpenSSL situation, but failure to run
a patch by the upstream developers was not a component of it.
Posted Aug 28, 2009 0:12 UTC (Fri) by rlk (guest, #47505)
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.
Posted Aug 29, 2009 20:51 UTC (Sat) by dirtyepic (subscriber, #30178)
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.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds