Re: Packaging and patching [LWN.net]

Re: Packaging and patching

Posted Aug 24, 2009 17:20 UTC (Mon) by jimi (guest, #6655)
In reply to: Re: Packaging and patching by nevyn
Parent article: On properly packaging perl

Quote:
So you go to all the effort of finding the bug, and documenting the correct fix etc. ... but don't bother to spend 5 minutes opening a distro. bug saying "X is the wrong fix, this is the upstream fix".

This is absolutely the wrong attitude and workflow pattern. The software developers should have no responsibility at all to file bugs to various distributors' mailing lists. The job of a distributor is to package the original source and optionally patch *and notify the upstream developers* of any bugs. This notification must go from distributor to developer, not the other way around. The article notes that Red Hat would have preferred that the perl guys had filed a bug in the Red Hat bug tracking system. That is completely the wrong expectation. It is Red Hat who should possibly be filing bugs, not the other way around.

There is a possible exception to this rule: when the upstream developers are unreachable. In that case the distributor may choose to become the new maintainers of the software.

(Log in to post comments)

Re: Packaging and patching

Posted Aug 24, 2009 18:41 UTC (Mon) by nevyn (subscriber, #33129) [Link]

So you go to all the effort of finding the bug, and documenting the correct fix etc. ... but don't bother to spend 5 minutes opening a distro. bug saying "X is the wrong fix, this is the upstream fix".
This is absolutely the wrong attitude and workflow pattern. The software developers should have no responsibility at all to file bugs to various distributors' mailing lists. The job of a distributor is to package the original source and optionally patch *and notify the upstream developers* of any bugs. This notification must go from distributor to developer, not the other way around.

FFS, read what I wrote. Upstream had already seen the patch the distro. did ... and added release notes about how they'd fixed it differently (to stop other problems). But couldn't spend the couple of minutes directly telling the distro? ... and this is the distros. fault for "not doing it's job". I think not.

But in the general case ... Yes, in a software developers perfect world they'd release upstream code full of "features". Distros. would then fix everything for them, and spend huge amounts of time rewritting those patches to make the developers happy while they spend their time adding more features.

Back in the real world packagers are often only spending a fraction of their time doing packaging, often among a bunch of packages, so that "blah install random-crack" works. They aren't unpaid upstream minions, and they sure as hell aren't paid for their "job". Yes, they are hopefully following development in some way, but they are still unpaid humans and can easily miss things.

On the other side upstream developers are often spending a majority of their time on a 1-3 projects. So those upstream developers spending an hour a month or so to make sure the packaging in (at least) the major distros. isn't broken in some way, doesn't seem like too much to ask IMNSO.

And, yeh, for larger projects (like perl) you might expect that the distros. have more resources to put towards upstream ... but at the same time upstream will often have lots more resources to look downstream.

Re: Packaging and patching

Posted Aug 25, 2009 0:10 UTC (Tue) by rlk (guest, #47505) [Link]

In this particular case (the Gutenprint issue) I did report it to my contact at the particular distribution I use. He ack'ed it, but it still didn't get changed. I only found out much later that this particular hack got propagated to other distributions. It wasn't a packaging problem, by the way. It was a badly conceived patch -- more like the Debian OpenSSL debacle than the Perl issue.

Checking all of the major distributions -- let's say, Fedora, Ubuntu, OpenSUSE, Debian unstable, Mandriva -- is a lot of work. It also means having the disks to do a lot of installations, the time to spend downloading the latest bits, the time to run tests, and so forth. No, this isn't practical.

Our automated test suite wouldn't have caught this in any case, since the problem was that the definition of letter and A4 paper was changed in a way that's legal within Gutenprint (and would therefore not fail functional and regression testing) but which would yield unexpected results.

The interaction I would have preferred is:

* Distributor files a bug/complains on the -devel mailing list that the behavior is unacceptable.

* We reply that it's behaving as designed.

* Distributor says "well, maybe so, but but it's still broken and we need to do something about it."

* Maybe we figure out the ultimate solution and get a fix in time for the next release (in which case everyone's happy) or maybe not, and distributor proposes the particular hack they actually did. More likely the latter, since the ultimate fix needed quite a bit of testing to get right.

* Distributor probably decides, after discussion, to accept that borderless printing won't work to those paper sizes and tells us that they're going to release with it. We suggest that they release note what's going on and keep checking back for a real fix.

* We get the fix out a bit quicker than we ultimately did, since we realize how critical it is in the real world; distributor picks it up and either patches the current release or at least makes sure the next release has the real fix (without applying the bogus patch again).

Re: Packaging and patching

Posted Aug 27, 2009 7:42 UTC (Thu) by job (guest, #670) [Link]

I expect a package maintainer to have a clue what changes went into the package they maintain. At least for security reasons, so when upstream gets hacked and/or goes crazy and inserts malware in the code it gets caught.

Otherwise all security that surround distributions is for nothing if they package whatever comes upstream (via unsecured FTP sites and whatever).

Not even reading the release notes is in my opinion very far from having a clue what changes are applied!