On Thu, 17 Nov 2011 20:26:33 +0000, Ben Hutchings <b...@decadent.org.uk> wrote: >On Thu, Nov 17, 2011 at 09:08:17PM +0100, Marc Haber wrote: >> On Thu, 17 Nov 2011 11:00:26 +0100, Adam Borowski >> <kilob...@angband.pl> wrote: >> >For example: you download the current point release, burn it to a CD >> >preparing to install a bunch of servers the next day... then suddenly >> >there's a new stable update and installation mysteriously fails. >> > >> >Wouldn't it be better to not delete superseded packages, at least for base? >> >> I would second that. A site I work for was severely bitten by the last >> squeeze point release since the kernel ABI changed and the kernel >> module udebs (loaded from a rsynced mirror) did not fit the (unsynced) >> kernel/initrd from the PXE server any more, resulting in newly >> deployed servers not even finding their disks. > >I can't imagine why you would expect this to work.
I wouldn't. The site was just surprised by the point release and did notice the deployment failure well before the announcement of the point release was received. This deployment setup has been in effect for a while, so I'd guess that this point release was the first to break compatibility between older kernel/initrd and current kernel udebs. If this is in fact the rule, I need to investgate why things used to work for years, but not having older point releases around any more, this is kind of hard to reproduce. >> Additionally, the new[1] tg3 driver broke compatibility with the tg3 >> chip built into IBM's HS12. The site in question would have rejected >> the last point release for that reason, if it were possible to go >> back. >> >> Greetings >> Marc >> >> [1] Why the heck do we allow changes like this in stable point >> releases? > >Just point to the bug report and stop stirring. Do you really think that this tone to users of your software will get you any friends? You're being unnecessarily rude and impolite. #645308, by the way. > I'm sorry this has >introduced a regression for these systems, but you have a workaround >and the backport enabled installation on many other systems. In nearly all non-kernel issues, we don't care zilch about enhancing support and new features if there is the slightest chance of breaking existing setups inside a stable release. I fail to see why the kernel is so special that it warrants an exception. In fact, the kernel is the last component of a distribution I would be willing to accept a "more features" upgrade in a stable point release because of the vast variety of things that can go wrong when a driver is updated _and_ the fact that there is no way to install x.y.z-1 after the release of x.y.z. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/ Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/e1rrrmd-0008id...@swivel.zugschlus.de
