Created attachment 185102 [details]
Currently some ports depend on UUID library distributed by linux. This dependency is satisfied by misc/e2fsprogs-libuuid, which is a slave port of sysutils/e2fsprogs, which is a set of utilities and library to manipulate an ext2, ext3 or ext4.
Normally, UUID library is distributed by util-linux package, see https://github.com/karelzak/util-linux and https://en.wikipedia.org/wiki/Util-linux
Taking UUID from e2f is wrong, because this isn't where it normally comes from.
I created a new port devel/libuuid which builds only libuuid part of util-linux.
I suggest, exp-run is done after replacing all uses of misc/e2fsprogs-libuuid with devel/libuuid:
> libuuid.so:misc/e2fsprogs-libuuid -> devel/libuuid
I found 21 such ports.
Or, if exp-run isn't considered to be required, this is fine too.
Mat, do you have an opinion?
Created attachment 185103 [details]
None at all.
Then this port should be committed, and the following replacement shouldbe made: libuuid.so:misc/e2fsprogs-libuuid -> libuuid.so:devel/libuuid
Hi Yuri, any update on this one?
(In reply to Ben Woods from comment #4)
This needs to be committed, but it will replace e2fsprogs-libuuid that is heavily used. All numerous dependencies need to be retested.
Any news here?
Is there any update here? The x11/fontconfig-2.13.1 upgrade requires libuuid, and having it split out would be nicer.
(In reply to Tobias C. Berner from comment #7)
I'll look if I could install a separate libuuid with a different name first to not conflict with the other one.
There are 95 ports that depend on libuuid, and the port is trivial.
I'll just replace them all. Will do tonight if there would be no unexpected problems.
I will rebuild all ports depending on uuid overnight and will commit the change if they succeed.
This port is ugly, what is the problem with misc/e2fsprogs-libuuid ?
Created attachment 210908 [details]
(In reply to Antoine Brodin from comment #11)
> This port is ugly, what is the problem with misc/e2fsprogs-libuuid ?
libuuid is not related to e2fsprogs, yet it is merged with it.
e2fsprogs is filesystem utilities, and libuuid is UUID handling library.
bapt@ has a cleaner patch.
Let's see what we get from the -exp run with bapt's
Note that e2fsprogs-libuuid installs the executables, too.
We cannot skip them. If licensing is an issue, we could install the executables separately.
I have not checked if libuuid from util-linux has all the features that e2fsprogs's has - but it appears that they might be related and in that case it might become acceptable to commit a modified version of the port (or two ports) and replace e2fsprogs-libuuid.
The precondition is that we do not remove any features (library/daemon/executable operation modes) and a sheer -exp run only reveals build issues, but not many run-time issues, if, say, a programm calls uuid to generate UUIDs.
I added my take on what should be done here (see the review URL)
Note that while doing that change, I have also done the same thing for libblkid (not sure we want that, but that is what others are doing as well and the version).
(In reply to Matthias Andree from comment #15)
on the binaries added by uuid package, I can probably readd uuidgen, but uuidd is not compatible anymore with FreeBSD (using signalfd), is there a real usage of uuid on FreeBSD working it worth porting it?
Since there is no progress and no real argument why we need to go through the hassle, let's kill this effort.
reopening because someone actually came up with a good reason to conduct this effort. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251489.
(In reply to Baptiste Daroussin from comment #17)
I don't mind losing uuidd for now, but we should plan this properly.
To that end, I propose to commit this in April or May so it can get a few weeks of exposure before it trickles down into the quarterly branch.
What is the result of -exp run?
Is this the same libuuid.so that devel/util-linux installs? The UUID part can be split out into a separate port.