e2fsprogs builds and installs obsolete version of blkid

e2fsprogs builds and installs obsolete version of blkid

[Kiselev, Oleg]

The e2fsprogs contains a version 1.0.0 of `blkid`.  This version does not support flags that the current kernel install scripts pass to `blkid`.  By building and installing e2fsprogs I ended up replacing blkid 2.30.2 with 1.0.0, which broke kernel packaging.  This is easily fixed by doing `yum reinstall util-linux`, which reinstalls the correct version blkid.  

This mess could be avoided if e2fsprogs either included a more modern version of blkid, or perhaps did not include blkid at all, since a more current version of this utility is maintained and installed through other packages.

(Finding https://forums.centos.org/viewtopic.php?t=69655 helped a lot in figuring out why my kernel build started failing all of a sudden)

Re: e2fsprogs builds and installs obsolete version of blkid

[Theodore Ts'o]

On Tue, Apr 05, 2022 at 11:15:22PM +0000, Kiselev, Oleg wrote:
> The e2fsprogs contains a version 1.0.0 of `blkid`.  This version
> does not support flags that the current kernel install scripts pass
> to `blkid`.  By building and installing e2fsprogs I ended up
> replacing blkid 2.30.2 with 1.0.0, which broke kernel packaging.
> This is easily fixed by doing `yum reinstall util-linux`, which
> reinstalls the correct version blkid.
> 
> This mess could be avoided if e2fsprogs either included a more
> modern version of blkid, or perhaps did not include blkid at all,
> since a more current version of this utility is maintained and
> installed through other packages.
> 
> (Finding https://forums.centos.org/viewtopic.php?t=69655 helped a lot in figuring out why my kernel build started failing all of a sudden)

The blkid and uuid libraries were moved from e2fsprogs from util-linux
on most Linux distributions.  However, these libraries are still
needed to compile e2fsprogs, and they are needed for non-Linux
operating systems, including FreeBSD, Illumos, etc., and some Linux
systems, such as Android.  That's why they haven't been removed.

If you install the RHEL/Fedora packages libblkid-devel and
libuuid-devel before you run run e2fsprogs's configure script, then it
will use the system versions of libblkid and libuuid, which will do
the right thing.

(For Debian / Ubuntu the packages names are libblkid-dev and uuid-dev,
but for these distributions it's better to just run
"dpkg-buildpackage" since that will automatically build the Debian
packages with all of the correct configure options via the
debian/rules file, and the Build-Depends: declaration in
debian/control will automatically enforce that you have all of the
correct build prerequites installed.)

If you hand done the simple thing that most novice users do, which is
to just run "./configure ; make", then the binaries will statically
link the old versions of blkid and uuid and that will work as well.
You just ran into the case where (a) you knew enough to enable ELF
share libraries, but (b) didn't know enough to install the system
libraries instead, and (c) then did a "make install" instead of using
a package manager to mediate installation of the programs.

I'm sorry that happened to you, but it's a relatively rare
combination, and the fact remains that there are other users of
e2fsprogs besides Linux, and unfortunately, many open source packages,
including util-linux and systemd, suffer from the "All The World Runs
Linux" disease, which seems to be an updated form of the disease, "All
the World's a Vax"[1].  (This is also why it would take more work than
it's worth to try to backport newer versions of blkid into e2fsprogs.)

Cheers,

      	   	       	    	      - Ted

[1] From: https://www.lysator.liu.se/c/ten-commandments.html

    Commandment #10:
       Thou shalt foreswear, renounce, and abjure the vile heresy which
       claimeth that ``All the world's a VAX'', and have no commerce with
       the benighted heathens who cling to this barbarous belief, that
       the days of thy program may be long even though the days of thy
       current machine be short.
    
    This particular heresy bids fair to be replaced by ``All the
    world's a Sun'' or ``All the world's a 386'' (this latter being a
    particularly revolting invention of Satan), but the words apply to
    all such without limitation. Beware, in particular, of the subtle
    and terrible ``All the world's a 32-bit machine'', which is almost
    true today but shall cease to be so before thy resume grows too
    much longer.

Re: e2fsprogs builds and installs obsolete version of blkid

[Kiselev, Oleg]

Got it.  There was no mention of installing libblkid-devel and libuuid-devel in the INSTALL file.  Now that I know what to look for, the ./configure actions with blkid make sense.

On 4/6/22, 5:49 AM, "Theodore Ts'o" <tytso@mit.edu> wrote:

    CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



    On Tue, Apr 05, 2022 at 11:15:22PM +0000, Kiselev, Oleg wrote:
    > The e2fsprogs contains a version 1.0.0 of `blkid`.  This version
    > does not support flags that the current kernel install scripts pass
    > to `blkid`.  By building and installing e2fsprogs I ended up
    > replacing blkid 2.30.2 with 1.0.0, which broke kernel packaging.
    > This is easily fixed by doing `yum reinstall util-linux`, which
    > reinstalls the correct version blkid.
    >
    > This mess could be avoided if e2fsprogs either included a more
    > modern version of blkid, or perhaps did not include blkid at all,
    > since a more current version of this utility is maintained and
    > installed through other packages.
    >
    > (Finding https://forums.centos.org/viewtopic.php?t=69655 helped a lot in figuring out why my kernel build started failing all of a sudden)

    The blkid and uuid libraries were moved from e2fsprogs from util-linux
    on most Linux distributions.  However, these libraries are still
    needed to compile e2fsprogs, and they are needed for non-Linux
    operating systems, including FreeBSD, Illumos, etc., and some Linux
    systems, such as Android.  That's why they haven't been removed.

    If you install the RHEL/Fedora packages libblkid-devel and
    libuuid-devel before you run run e2fsprogs's configure script, then it
    will use the system versions of libblkid and libuuid, which will do
    the right thing.

    (For Debian / Ubuntu the packages names are libblkid-dev and uuid-dev,
    but for these distributions it's better to just run
    "dpkg-buildpackage" since that will automatically build the Debian
    packages with all of the correct configure options via the
    debian/rules file, and the Build-Depends: declaration in
    debian/control will automatically enforce that you have all of the
    correct build prerequites installed.)

    If you hand done the simple thing that most novice users do, which is
    to just run "./configure ; make", then the binaries will statically
    link the old versions of blkid and uuid and that will work as well.
    You just ran into the case where (a) you knew enough to enable ELF
    share libraries, but (b) didn't know enough to install the system
    libraries instead, and (c) then did a "make install" instead of using
    a package manager to mediate installation of the programs.

    I'm sorry that happened to you, but it's a relatively rare
    combination, and the fact remains that there are other users of
    e2fsprogs besides Linux, and unfortunately, many open source packages,
    including util-linux and systemd, suffer from the "All The World Runs
    Linux" disease, which seems to be an updated form of the disease, "All
    the World's a Vax"[1].  (This is also why it would take more work than
    it's worth to try to backport newer versions of blkid into e2fsprogs.)

    Cheers,

                                          - Ted

    [1] From: https://www.lysator.liu.se/c/ten-commandments.html

        Commandment #10:
           Thou shalt foreswear, renounce, and abjure the vile heresy which
           claimeth that ``All the world's a VAX'', and have no commerce with
           the benighted heathens who cling to this barbarous belief, that
           the days of thy program may be long even though the days of thy
           current machine be short.

        This particular heresy bids fair to be replaced by ``All the
        world's a Sun'' or ``All the world's a 386'' (this latter being a
        particularly revolting invention of Satan), but the words apply to
        all such without limitation. Beware, in particular, of the subtle
        and terrible ``All the world's a 32-bit machine'', which is almost
        true today but shall cease to be so before thy resume grows too
        much longer.