Bug 506360

Seems the replacement for /lib/udev/vol_id is /sbin/blkid

Created attachment 348169 [details]
a patch that might work

Even if intended, this feels like a nasty regression with udev.  While the livecd-iso-to-disk case is relatively easy to make work (although it changes what we depend on which could be bad), removing vol_id means that one now has to have different sets of udev rules for different versions of udev as you depend on needing vol_id for older versions or the _new_ blkid -o udev option for newer versions.

This is all but guaranteed to trip up things outside of the base udev shipping rules files :(

(oh, and Matthias -- applied your patch to livecd-iso-to-disk.  but there are other things in the livecd stack that will not work with udev just dropping helpers like this :/)

Well, udev helpers and rules may change whenever needed.

_Nothing_ outside of udev must ever call them, or rely on specific rule content, besides the ordering.

External tools can only depend on the properties udev offers with udevadm or libudev, everything else is not public and 100% private to udev, and may change any time.

Jeremy - my patch was good enough to produce a stick, but it wouldn't boot :-(

(In reply to comment #5)
> Well, udev helpers and rules may change whenever needed.
> 
> _Nothing_ outside of udev must ever call them, or rely on specific rule
> content, besides the ordering.
>
> External tools can only depend on the properties udev offers with udevadm or
> libudev, everything else is not public and 100% private to udev, and may change
> any time.  

The fact of the matter is that things do as that has never been made clear to anyone who would have ended up using them.  There's nothing in the man page to say not to and there even *is* a man page.  Hardly what you expect for something that should never be called.

Also, with the above statement, it means that something like dracut can't ship any rules which are needed for making systems boot because you're saying "I don't care, I'll break things if and when I choose."  And thus we end up tying one version of dracut to a specific version of udev.   Or that anaconda can't ship rules for its own discovery and adding to the environment.  Or DeviceKit-disks (which also uses vol_id, btw).  Or any of a number of other packages which ship their own udev rules for _whatever_ reason.  Or that I as a user wrote for my own system to do something very specific to my system.

Should be trivial to make vol_id a wrapper around blkid, no ?

(In reply to comment #7)
> Or
> DeviceKit-disks (which also uses vol_id, btw).

And we are not going to whine when stuff changes. This is low-level Linux at the plumbing layer: there's no silly guarantees of any stability (except where explicitly stated, e.g. udev rules and certain udev attributes such as ID_FS_TYPE etc.) because we don't want that to impede progress. It is up to distributors to sort these things out. Not to whine about it.

This is not to say that you can't (or shouldn't have) used vol_id (or similar handy tools) directly; sometimes it's handy to do so, especially when things are in flux (and e.g. udev doesn't have anything similar). You are just not supposed to whine about it.

Frankly, I find it very disturbing that you use the word regression here. Maybe it's a pet peeve of mine, but so many people keep abusing that word - to the extent that it is beginning to lose it's meaning. Listen, if something in glibc or gtk+ changes (where this is an expectation of stable API/ABI), you can use the word regression. But not for this. No one ever promised you a rose garden.

(In reply to comment #9)
> (In reply to comment #7)
> > Or DeviceKit-disks (which also uses vol_id, btw).
> 
> And we are not going to whine when stuff changes. This is low-level Linux at
> the plumbing layer: there's no silly guarantees of any stability (except where
> explicitly stated, e.g. udev rules and certain udev attributes such as
> ID_FS_TYPE etc.) because we don't want that to impede progress. It is up to
> distributors to sort these things out. Not to whine about it.

I'm not whining as a distributor.  I'm whining as an upstream maintainer of a piece of software that thought I could depend on another piece of software to not just drop documented functionality without warning.  Saying that everything is subject to change is entirely not helpful.  Yes, it's plumbing but that doesn't mean that you can just remove joints from the pipes unless you want everybody to get soaked.

> This is not to say that you can't (or shouldn't have) used vol_id (or similar
> handy tools) directly; sometimes it's handy to do so, especially when things
> are in flux (and e.g. udev doesn't have anything similar). You are just not
> supposed to whine about it.

Gee, so I should have used it but when it goes away, I shouldn't and I should just take my lumps and change everything and require the world to update their plumbing to use my new release?  

> Frankly, I find it very disturbing that you use the word regression here. Maybe
> it's a pet peeve of mine, but so many people keep abusing that word - to the
> extent that it is beginning to lose it's meaning. Listen, if something in glibc
> or gtk+ changes (where this is an expectation of stable API/ABI), you can use
> the word regression. But not for this. No one ever promised you a rose garden.  

I'm not asking for a rose garden, I'm asking for a modicum of respect for people using software.  Especially, as mclasen notes, it's not like this is anything other than gratuitous breakage -- vol_id can easily be implemented as a wrapper around newer blkid if newer udev wanted to do so.  And I guess I'll be spending some time later to do that rather than other things.

And maybe it's my pet peeve, but I'm tired of people abusing "low-level" and saying that if someone complains about low-level pieces change, they're automatically branded as a "whiner".

> > And we are not going to whine when stuff changes. This is low-level Linux at
> > the plumbing layer: there's no silly guarantees of any stability (except where
> > explicitly stated, e.g. udev rules and certain udev attributes such as
> > ID_FS_TYPE etc.) because we don't want that to impede progress. It is up to
> > distributors to sort these things out. Not to whine about it.

Right. As said, there are no guarantees about stuff in the _private_ /lib/udev/ and /dev/.udev/ directories, and there never have been. Only the device properties can reliably be used, and they stay exactly the same after the blkid switch.

The executables in /lib/udev/ are a very specific udev implementation detail, we could move all of them into the main daemon one day, without further notice. 

> vol_id can easily be implemented as
> a wrapper around newer blkid if newer udev wanted to do so.  And I guess I'll
> be spending some time later to do that rather than other things.

Let's please just fix the users instead, and leave the implementation details of /lib/udev/ to udev and nothing else.

> The fact of the matter is that things do as that has never been made clear to
> anyone who would have ended up using them.  There's nothing in the man page to
> say not to and there even *is* a man page.  Hardly what you expect for
> something that should never be called.

That's a good point.

I'll remove all the dummy man pages, vol_id was the only useful man page anyway.
 
> Also, with the above statement, it means that something like dracut can't ship
> any rules which are needed for making systems boot because you're saying "I
> don't care, I'll break things if and when I choose."

Sure it can ship rules, what do you mean? It can just not use random executables in /lib/udev/ without proper coordination. And stuff needed for booting should already be called anyway, and available as properties in the event itself. If not, we will add it to the proper place in the main repo.

> And thus we end up tying
> one version of dracut to a specific version of udev.

I don't think so. You may disagree with vol_id being deleted, but I don't think that statement holds in that context.

> Or that anaconda can't
> ship rules for its own discovery and adding to the environment.  Or
> DeviceKit-disks (which also uses vol_id, btw).  Or any of a number of other
> packages which ship their own udev rules for _whatever_ reason.

Again, you can ship "whatever" udev rules, and all will be fine. There have been no changes in that area for a very long time.

But you can not just call udev callouts without coordinating it with the udev maintainers. In most cases, you just have to add such rules to the main repo, if you require some functionality. And provided udev functionality includes rules syntax and the event properties, but not the used callouts.

> There's nothing in the man page to
> say not to and there even *is* a man page.
> Hardly what you expect for
> something that should never be called.
> 
> That's a good point.

These man pages are gone now, beside the one for scsi_id, where the binary is exported to /sbin on some distributions, and also used by the multipath tools.

I also added a section in the README about the private nature of the content of /lib/udev/.

(The whole long vol_id story is a bit unfortunate, it would have never existed when the original blkid maintainers would have been willing to make it usable for udev. That is all solved properly now by Karel who merged libvolume_id and libblkid in a new blkid version in util-linux-ng. And /sbin/blkid, unlike vol_id, offers a stable interface.)

*** Bug 508611 has been marked as a duplicate of this bug. ***

(In reply to comment #6)
> Jeremy - my patch was good enough to produce a stick, but it wouldn't boot :-(  

For what it's worth, I' m posting this from a session run of a Fedora 11 Live USB stick, produced with your patch (which applied cleanly against current Rawhide) using this command:
    livecd-iso-to-disk --overlay-size-mb 256 --home-size-mb 256 --unencrypted-home Fedora-11-i686-Live.iso /dev/sdb1

There might be other issues, of course, but it does at least boot here.

assigning back to livecd-tools

I committed to git and will be doing a new livecd-tools build either tomorrow or Monday (waiting to let the dracut changes settle out a little)