Replace e2fsprogs libblkid and libuuid by util-linux implementations

[mandree]

Summary

In the linux world, but also in pkgsrc, the libuuid and libblkid implementation
used by e2fsprogs, but in the case of libuuid also used by any other programs
do come from util-linux (where they are actively maintained) and not from e2fsprogs.

Follow their path and use the same source.

In the process of updating libuuid the uuid daemon has been lost, the upstream
implementation now uses linux only interfaces (signalfd which makes it incompatible
with FreeBSD). So far no investigation has been made to port it to FreeBSD

Adapt the e2fsprogs port to make use of the new libuuid and libbklid.

The investigation has been made on the following sources:

• archlinux
• debian
• fedora
• gentoo
• pkgsrc

Note that so far only OpenBSD and FreeBSD are using e2fsprogs-libuuid

[mandree]

I don't see the libuuid/libblkid versions referenced here. They need to be included either as patches, or by a revision-proof reference.

[bapt]

In D23312#511182, @mandree wrote:

I don't see the libuuid/libblkid versions referenced here. They need to be included either as patches, or by a revision-proof reference.

Sorry byt I don't understand what you mean by version referenced here? this is libuuid 2.34 as stated by the PORTVERSION

[mandree]

In D23312#511187, @bapt wrote:

In D23312#511182, @mandree wrote:

I don't see the libuuid/libblkid versions referenced here. They need to be included either as patches, or by a revision-proof reference.

Sorry byt I don't understand what you mean by version referenced here? this is libuuid 2.34 as stated by the PORTVERSION

@bapt, what I was trying to say is: I don't see the referenced misc/libuuid and possibly misc/libblkid ports. They have not yet been commited, nor are they part of this reviews diff D23312 (possibly the diff command line wasn't including "-N" to include new files), nor are there any non-obsoleted attachments to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221293 - so I don't know what I could review against, and committing the raw D23312 diff I can download here would very obviously break the tree because it adds nonexisting SUBDIR+= lines to ports/misc/Makefile.

Please someone add the intended misc/libuuid and possibly misc/libblkid ports to this review, or to a PR and include the exact URL of the attachment, or to a new reviews.f.o or bugzilla.f.o item that we can reference as a requisite.

$ diffstat <D23312.diff | grep misc
 misc/Makefile                        |    4 ++--
 misc/ignition-fuel-tools/Makefile    |    4 ++--

[bapt]

Actually add libuuid and libbklid

[bapt]

I don't have enough time to spend on this, neither time to argue to explain why or not this change is good. Feel free to take over, continue or give up on this.

[mandree]

Yuri, please change the libuuid/libblkid ports such that it

1. installs uuidgen
2. does not break downstream builds that might include the _types.h files directly.

[yuri]

Baptiste took over and updated the patch with his patch. I think he should update it further. -)

[mandree]

In D23312#512494, @yuri wrote:

Baptiste took over and updated the patch with his patch. I think he should update it further. -)

Try and convince him - until then, you are the proponent and are responsible because in the current shape I will not consent to removal of the features (uuidgen), and as mat@ and I have pointed out earlier, the change is weakly motivated - and the claim the libs were unmaintained inside e2fsprogs is unproven so far, and e2fsprogs is maintained.

So either you get things into an acceptable shape, or you prove with facts why AND HOW util-linux's libuuid/libblk are better, or we bury this approach.

[mandree]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489 came up with a reason to restart this endeavour. Any takers for getting the patch updated? If someome wants to take responsibility, use the action "commandeer revision" which makes you the new owner.

[yuri]

The port devel/util-linux provides libuuid.so

[mandree]

Unfortunately though, util-linux conflicts with other packages, partial list in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489

[arrowd]

Bumped into this problem at $WORK. It is a pity that this change was abandoned.

[yuri]

@arrowd

It would be nice if this would be committed if all dependencies build with util-linux.

[mandree]

It is a lot of preparation fixing all the fallout of switching. There are lots of util-mini tools that break the system one way or another.

[arrowd]

My company sposnored an another take on this change.

This is still a WIP and libuuid/libblkid ports are referencing commits from
master branch. Once upstream accept our patches and make a new release, the
ports will be switched to a release tarball.

For now we're putting this here for the reviewing purposes.

[mandree]

@arrowd @yuri Before I start spending my scarce time on reviews in the light of existing sponsoring:

• have all the breakages of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489#c3 and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489#c4 been addressed?
• how do we deal with conflicts from, say, hardlink and getopt, in particular?
• do we have we complete self-test and run-time test results that programs switched from e2fsprogs-* to plain util-linux libraries work?
• when is the final version that "uses a release tarball" due?

I also think that if we have truckloads of changes to make the basic libraries build, such as the big meson patch for misc/libuuid, that are not in the upstream distributions of util-linux and related libraries yet, it's premature to merge anything. In the meanwhile, I'll reopen 251489 to give this more exposure.

[arrowd]

• Update to util-linux 2.41 that contains our upstreamed patches
• filesystems/e2fsprogs-core: Stop linking util-linux libs statically, because upstream stopped providing it
• Did a mini-exprun on all libuuid libblkid consumers

[arrowd]

Ping.

[mandree]

1. Veto for now.
2. Technically: Do we happen to have a computer that has all non-conflicting ports installed so that we can search it for scripts using the uuidd? I wouldn't like to break their runtimes.
3. Organizationally: I am not comfortable with a new maintainer, or one external to the project, for a high-profile port. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489 for conditions under which I offer to maintain libuuid.

misc/libuuid/Makefile

7

Veto. The maintainer does not have a track record, can't be found in a web search, and maintains no other ports. I consider the risk for supply chain attacks too high. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489

[arrowd]

• Fixes for the MAINTAINER section

[arrowd]

• Rebase and update

[mandree]

filesystems/e2fsprogs-core/Makefile

254

The static link needs to remain.

[mandree]

A similar thing has been committed as of today, which had been prepared by @arrowd with contributions from Alexander Shursha <[e-mail]> who set up two clean libuuid/libblkid ports that are based on meson build of util-linux.

[mandree]

Abandoning, overcome by events that have equivalent effect as what this review set out to do too long ago when I could not spend sufficient time on this. My apologies to everyone who has been waiting and inconvenienced for so long.