Re: upstart: please update to latest upstream version
- To: Marco d'Itri <firstname.lastname@example.org>
- Cc: email@example.com
- Subject: Re: upstart: please update to latest upstream version
- From: Goswin von Brederlow <firstname.lastname@example.org>
- Date: Thu, 01 Mar 2012 09:41:18 +0100
- Message-id: <[🔎] email@example.com>
- In-reply-to: <20120229195627.GA27596@bongo.bofh.it> (Marco d'Itri's message of "Wed, 29 Feb 2012 20:56:27 +0100")
- References: <20120224212719.GJ24406@codelibre.net> <firstname.lastname@example.org> <20120229183503.GA25325@bongo.bofh.it> <email@example.com> <20120229195627.GA27596@bongo.bofh.it>
Marco d'Itri <firstname.lastname@example.org> writes:
> On Feb 29, Russell Coker <email@example.com> wrote:
>> One thing that would be really convenient in such situations is the ability to
>> have the old and new versions of the package installed such that the new
>> version would run the old version if appropriate.
> Yes. Except that this was not applicable to udev because the
> system-facing interfaces too were different between different versions.
> As I already explained countless times.
What would have been trivial to do is to have udev-x.y packages that are
coinstallable and a simple udev binary that checks the kernel version
and features and then starts the right udev-x.y. Examples for this kind
of flexibility would be xen or lvm.
But then again udev also broke udev rules so you had to change the
conffiles to match the udev version. But at least that only affected
some rules, not all of udev, and was a more gradual effect.
But you've all heard that before and (you and upstream) still ignore it
and udev will keep having these problems and keep sucking for that
reason. By now I don't expect that to change. So EOD.
Udevs shortcommings weren't the point anyway, just an example to show
that we shouldn't have all of Debian depend solely on something similar.