Provide optional instructions to move ACL/Attr/glib libs to /lib

[willimm]

There is a pretty crucial flaw in the ACL/Attr instructions: the libraries of ACL/Attr are in /usr/lib. Now, at first glance, this is not such a problem, but if you have /usr on a separate partion and rebuild Coreutils after ACL/Attr per the instructions, all of the Coreutils programs (including the ones that reside in /bin) link against ACL/Attr, and if the /usr partion fails, all of the Coreutils apps that linked aganst ACL/Attr are unusable.

See how serious this is? I'd move the ACL/Attr libs to /lib to avoid this problem. You also have to put the .la files for ACL/Attr in /lib, as UDEV and KDE will fail to build without them (I learned this the hard way).

[Guy Dalziel]

I hardly think that such drastic action is needed. Coreutils has a --disable-acl option that should fix this problem.

[willimm]

Replying to gdalziel:

I hardly think that such drastic action is needed. Coreutils has a --disable-acl option that should fix this problem.

Well:

1. Most distros put ACL/Attr on /lib, and it's a very good idea to use some ideas from them.
2. Udev uses ACL/Attr too.
3. If ACL/Attr is on /lib after Coreutils is rebuilt, it complies with the FHS.

[Guy Dalziel]

Nothing is forcing you to compile against ACL. If you compile coreutils or udev later on then it is your responsibility to move ACL to /lib. We put ZSH in /bin, but that doesn't mean that we suddenly have to change the pages for libpcre and gdbm to go into /lib, the instructions for moving these libraries to /lib is available on the ZSH page. Therefore simply because a program compiles against something is not just cause to move it unless it is a required part of the base system - ACL is optional.

[willimm]

Replying to gdalziel:

Nothing is forcing you to compile against ACL. If you compile coreutils or udev later on then it is your responsibility to move ACL to /lib. We put ZSH in /bin, but that doesn't mean that we suddenly have to change the pages for libpcre and gdbm to go into /lib, the instructions for moving these libraries to /lib is available on the ZSH page. Therefore simply because a program compiles against something is not just cause to move it unless it is a required part of the base system - ACL is optional.

At least add instructions to move the ACL/Attr libs to /lib.

[Ag. Hatzimanikas]

Replying to willimm:

At least add instructions to move the ACL/Attr libs to /lib.

Make a patch and I will push it. As Guy already said you can use the zsh paradigm.

[DJ Lucas]

Guy, while I understand your argument for not using /usr/lib by default, I honestly believe that it is unfounded. I don't see the point in arguing against the suggestion to move them to /lib as both major consumers of the packages are required for booting the system. I mean, without recompiling either dependent package, what is the point of installing the libraries in the first place? It's an FHS issue, there really shouldn't be any question IMO. Any installed utilities (if any) belong in /usr/sbin (I can't see a case for ACLs in single user or in a non networked environment, but I could be missing something and they should go to /sbin), but there is no question whether the libraries belong in /lib (see below directed to William for the method).

Udev, I believe is going in to be rebuilt in BLFS IIRC, so this could soon become a BLFS ticket agian. If you or Ag don't want to mess with it, or plainly don't agree with me, I'll bring it up on -dev in a week or so for wider discussion (when I have time to do more than just blow hot air). ;-)

William, UDEV and KDE are broken if the build tools can't find the la files from the pc file, but I doubt that is actually the problem. Archives don't belong in /lib (though PAM is an exception). Sounds like you might be incorrectly passing --libdir=/lib to configure. The package should be installed with a /usr prefix, and the libraries moved to /lib and symlinks in /usr/lib to keep pkg-config happy, and finally versioned .so links recreated to point to the new location (there are a couple of examples of the readlink loop in the book now). I believe that my previously posted instructions to BLFS-Dev probably did not account for that problem (archives in /lib).

Ag, he can't use "the zsh paradigm" because coreutils isn't in BLFS, though it should at very least be mentioned on the ACL page that coreutils will need to be rebuilt along with a link to the Chapter 6 LFS page if the instructions are the same (and maybe it is already, I haven't read the new pages yet). Vice-versa in LFS.

I've intentionally chosen to leave the priority at high in light of my above opinion on the matter. If you disagree, feel free to drop it down. When I have the time, I'll bring it up on the dev mailing list for discussion.

OT: It may soon be time that these two packages go into LFS, probably not for a couple of years yet, but soon, so lets plan ahead. gudev (I think that was what first *needed* them) is just broken if it requires them when the system tools do not support ACLs, but that particular ticket shouldn't belong to {,B}LFS. :-)

[DJ Lucas]

Replying to dj@…:

Guy, while I understand your argument for not using /usr/lib by default

Obviously that should have read "for not using /lib by default..."

[DJ Lucas]

This amounts to adding the following to attr and then acl resp. (didn't bother with the loop).

mv /usr/lib/libattr.so.1.1.0 /lib &&
chmod 755 /lib/libattr.so.1.1.0 &&
rm -f /usr/lib/libattr.so.1 &&
ln -sf libattr.so.1.1.0 /lib/libattr.so.1 &&
ln -sf ../../lib/libattr.so.1.1.0 /usr/lib/libattr.so

mv /usr/lib/libacl.so.1.1.0 /lib &&
chmod 755 /lib/libacl.so.1.1.0 &&
rm -f /usr/lib/libacl.so.1 &&
ln -sf libacl.so.1.1.0 /lib/libacl.so.1 &&
ln -sf ../../lib/libacl.so.1.1.0 /usr/lib/libacl.so

[DJ Lucas]

Also, acl-2.2.49 is out and the links are bad. Google gave first hit to ​http://mirrors.igsobe.com/nongnu/

[DJ Lucas]

We'll add to this glib as well.

[Randy McMurchy]

Replying to dj@…:

When did the glib files get involved with this?

When was it ever discussed on -dev as is mentioned earlier in the ticket? Perhaps I missed it, though.

Additionally, see the Linux-PAM instructions for using the readlink command to find the version string. That way devs don't have to update it again.

[DJ Lucas]

Replying to randy@…:

Replying to dj@…:

When did the glib files get involved with this?

I mentioned it in the midst of the recent thread that kind of went in all directions. Additionally, libusb is required as well if you re-install udev (for gudev).

This is what is still 'broken' in my current build.

 dj [ ~/LFS/BLFS/BOOK-orig ]$ ldd /lib/udev/* 2>/dev/null | grep usr
	libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0xb7833000)
	libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0xb7696000)
	libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0xb7800000)
	libusb-1.0.so.0 => /usr/lib/libusb-1.0.so.0 (0xb7663000)
	libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0xb767e000)
dj [ ~/LFS/BLFS/BOOK-orig ]$ 

[Randy McMurchy]

Could we begin a new thread on -dev about moving anything other than the acl/attr libs? I must have missed it when the other thread "went in all directions".

[willimm]

So, the libs that we should provide instructions for moving to /lib because the rebuilt udev uses them:

• glib-2.0 (only move libglib-2.0.so.*)
• Both libusb libs (the compat 0.1 and the 1.0 versions)
• acl/attr, as mentioned before
• pcre is arleady taken care of, but we should probaly add instructions to the udev page.

[(none)]

Milestone 6.5 deleted

[Randy McMurchy]

Updated milestone to 6.7

[Randy McMurchy]

Changed some tickets from a defect to an enhancement

[Armin K]

ACL and ATTR issue is fixed in r9674 and r9676.

[bdubbs@…]

Milestone current deleted