Re: upstart: please update to latest upstream version
Ben Hutchings <ben@decadent.org.uk> writes:
> On Tue, Feb 28, 2012 at 09:58:01PM +0100, Goswin von Brederlow wrote:
>> Ben Hutchings <ben@decadent.org.uk> writes:
>>
>> > On Tue, Feb 28, 2012 at 04:51:18PM +0000, Roger Leigh wrote:
>> >> On Sat, Feb 25, 2012 at 12:17:43AM +0200, Uoti Urpala wrote:
>> >> > Roger Leigh wrote:
>> >> > > On Fri, Feb 24, 2012 at 04:20:47PM +0200, Uoti Urpala wrote:
>> >> > > > > [note: it's somewhat desirable for them to be optional on Linux
>> >> > > > > too, to prevent feature lock-in and future compatibility problems].
>> >> > > >
>> >> > > > Unix kernel development outside Linux is pretty limited, especially
>> >> > > > development for features other than server use. I think "avoid requiring
>> >> > > > Linux-specific features" would turn into "avoid technology developed
>> >> > > > after the 90s".
>> >> > >
>> >> > > This is missing the point. I'm not saying "don't use Linux-specific
>> >> > > features", I'm saying that use of Linux-specific features should be
>> >> > > /optional/, even on Linux. Only use them if present.
>> >>
>> >> > > Let's take cgroups as an example. They are an optional feature
>> >> > > even on Linux.
>> >> >
>> >> > As are several fundamental POSIX features.
>> >>
>> >> POSIX features, optional or not, are standard and will not change
>> >> incompatibly. If not present, one would expect an ENOSYS error return
>> >> and the code should cope with that eventuality.
>> >>
>> >> cgroups is both non-standard, changing rapidly, and does not have a
>> >> guaranteed future. It's somewhat controversial even amongst kernel
>> >> hackers. Relying on it is, to put it mildly, short-sighted.
>> > [...]
>> >
>> > This is FUD. The Linux kernel developers are very concerned with
>> > maintaining compatibility with existing userland programs, and the
>> > widespread use of systemd by other distributions means that the APIs
>> > it uses must be maintained.
>> >
>> > Ben.
>>
>> Yeah right. As witnessed by the number of times udev broke because the
>> kernel changed or udev forced a lock-step of both udev and kernel. Or
>> any number of other APIs.
>
> There has never been a requirement for lockstep upgrades, but yes
>From udev.preinst:
supported_kernel() {
local version
if [ "$1" ]; then
version="$1"
else
version="$(uname -r)"
fi
case "$version" in
2.[012345].*|2.6.[0-9]|2.6.[0-9][!0-9]*) return 1 ;;
2.6.[12][0-9]|2.6.[12][0-9][!0-9]*) return 1 ;;
2.6.3[0-1]|2.6.3[0-1][!0-9]*) return 1 ;;
esac
return 0
}
Meaning you need at least 2.6.32 for udev to work. There is no
compatibility with older kernels in udev. So when updating udev you also
have to update and reboot the kernel to at least 2.6.32. And that isn't
the first such version requirement in udev.
> there have been incompatible changes in the layout of sysfs, and yes
> that is annoying. As I understand it, the pain those changes caused
> has led to rather more careful manageemnt of sysfs today.
Lets hope it is improving. But that only shows that depending on
controversial linux features should still be a concern.
>> Linux kernel developers, at least some, don't seem to give a f**k. If
>> they break something they use they fix the userspace too.
>
> No, there are lots of kluges in the kernel to support old userspace.
> For example, the order in which fork() parent and child run is chosen
> to avoid breaking old versions of bash.
Which falls under "IF they use it too."
>> IF they use it
>> too. Distributions are left with having to support this by keeping APIs
>> and user space in sync and doing lock-step upgrades. Something that is a
>> huge pain with the kernel. Udev is the worst case example there since it
>> doesn't support multiple API versions at all and is quite prominent.
>
> Linux has config-time options to expose deprecated sysfs attributes
> and udev has had transitional versions that work with or without them.
Thats new. I had all my systems break because udev didn't support the
deprecated sysfs attributes and had to recompile the kernel to not have
them. But that isn't really the kernels fault. It's udevs fault for not
supporting both ways from the start.
> If a lockstep upgrade was required then it wouldn't have been possible
> to do online sarge-etch and lenny-squeeze upgrades at all.
I remember that for at least one upgrade you first had to upgarde to the
latest point release before doing a dist-upgrade or the version
requirements would have made upgrading impossible.
Don't get me wrong, I'm not saying having a lock-step upgrade between
packages is always avoidable. Far from it and it usualy is not a
problem. But if it involves the kernel and the boot process things
become rather more complicated and not all linux APIs aren't a stellar
example for smooth API changes. Quality in that regard varries widely
between subprojects.
Overall I'm verry much in the group that wants systemd in Debian. But as
an option, not a requirement. If haven forbid someone breaks cgroups it
is good that we can switch back to sysvinit, insserv or even upstart.
I'm also verry much for having a single source from which all configs
for init systems are generated if that is possible.
> Ben.
MfG
Goswin
Reply to: