On 06/17/2012 07:49 PM, Bryan Kadzban wrote:
> Armin K. wrote:
>> On 06/17/2012 12:00 AM, Bruce Dubbs wrote:
>>> Also, as with the discussion on BLFS support discussing updating
>>> glibc in place, I think I will put udev in the same category as too
>>> risky to update in place.
>>
>> Erm, why? What could go wrong?
>
> For udev, for for glibc?
>
> For glibc, it's pretty obvious: you need to replace ld-linux and libc at
> the same time (unlink both, then symlink the new versions), otherwise
> you'll end up with programs being exec()ed with a combination of those
> two files that come from different versions of glibc. Whether this is
> actually a problem or not depends on which glibc versions they are, of
> course, but there is at least a reasonable probability of an
> incompatibility between the memory layout that ld-linux creates, and the
> one that libc requires.
>
> You also can't replace ld-linux with "rm && ln -s", because ln won't be
> able to be exec()ed, since it requires ld-linux to do so.
>
Not glibc but udev. I've managed to (sort of) cleanly upgrade glibc. If
you are subscribed to blfs-support, you should have recieved that one.
> Now this can obviously be worked around (the tar idea is interesting,
> and yeah I think it'd work too, as long as both files and both symlinks
> are added to the tar) -- but the glibc installation rules in its
> Makefiles don't do that.
>
> For udev, it also depends on which version you're coming from, but see
> Bruce's previous posts in this thread for one thing that could go wrong
> -- the layout of /sys changed in a backward-incompatible way, and
> there's no way to run either current udevs with the old layout, or
> (many) old udevs with the current layout.
>
> There *might* be a few udev releases that work with both layouts, from
> back before the day the udev maintainers decided that the only upgrade
> path they'd support is the kernel working with older udevs (which it
> *doesn't* in the case of !CONFIG_SYSFS_DEPRECATED), but I don't know
> what versions they'd be. :-/
>
Oh right. Well, I'd rather choose some version in the middle of current
users' version and latest available version of udev and then do upgrade.
If everything works with the middle version, it should possibly work
with latest one with or without kernel/userspace/whatever modifications.
Not very easy or fun, but not impossible.
> But another incompatibility that comes to mind is the rules-file format.
> Current udev versions use ATTR / ATTRS, while earlier versions used
> SYSFS (and had no way to distinguish between "matching on the device
> being processed" and "matching on any single parent device"). See also
> the transition from NAME to KERNEL for everything except NICs, the
> transition from $sysfs{...} to $attr{...} or $attrs{...} in substitution
> strings, etc. A bunch of udev versions warned about the presence of the
> old constructs in the rules files they parsed, but that may have been
> removed now as well.
>
>
>
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
