On 07/10/2011 12:23 AM, Bruce Dubbs wrote: > Wayne Blaszczyk wrote: >> On 10/07/11 01:16, DJ Lucas wrote: >>> On 07/09/2011 01:45 AM, Wayne Blaszczyk wrote: >>>> On 04/07/11 09:42, Randy McMurchy wrote: >>>>> Hi all, >> ...snip... >> I totally agree in dropping /opt, there is just to much overhead in >> maintaining two sets of instructions. > For an LFS user who wants to experiment, being able to install to /opt > is important. When experimenting, we want to give the user a chance to > build without trashing the old system. It gives the option of backing up. > > For a user who is building only once, it probably doesn't make any > difference, but I think this is one of the more important services that > BLFS offers. > > I use it for qt, kde, fop, and ant. I don't generally build gnome, but > I did, I would want to put it into /opt. > Taking only Gnome for an example, it's just too difficult. Isolating it is *impossible* as there are way to many interdependent packages. Even if you install to /opt/gnome now, you have several different modules to account for in system locations (dbus, dconf, gconf, gio, gstreamer, etc) and they cannot exist in an alternate directory tree, not to mention the hoops to jump through to get all the data files in the right locations under /usr/share for things like internationalization and even pixmaps and icons. While I still haven't completed KDE, however, I believe that if you review your installation logs, you'll find the same is true there (or I suppose it is possible that KDE's conglomeration of packages fits better into this model). Self contained packages like QT and OpenOffice, I guess I can kind of understand. I used to use that isolation scheme myself, but for most of the other things placed into /opt today, I just don't see the purpose any longer as they are not actually isolated installations, and removing those packages can actually cause breakage. >> I too use a multilib system due to a work requirement of having to use >> Citrix ICACLient. What I've done was to build LFS + BLFS as 64 bit, then >> on another machine built LFS + BLFS as 32 bit, then copy all the >> necessary 32bit libraries over to the 64 bit machine. All the 32 bit >> stuff(lib + bin) I've managed to contain under /opt/32bit. I only have 2 >> sym-links pointing from /lib (ld.so and ld-linux.so). The reason I did >> it this way is that I didn't want to contaminate my pure 64 bit environment. > Seems reasonable to me. Unfortunately, this doesn't work for a couple of projects that I work with (specifically for XVM and AOSP in my case). No amount of LD_* and PATH exports can 'fix' this easily for me. Hopefully over the next few years, that will become a non-issue, but unfortunately, that is not the case today. >>> Agreed on all points above. What did you have in mind for LSB? A page of >>> links to other sections in the books? As it is now, LFS has about 75%, >>> maybe 80% coverage of Core. >> Either way, having links, or just moving the relevant BLFS packages into >> this new section. I think the LSB section should only cover what is not >> in LFS. > We already have > http://www.linuxfromscratch.org/lfs/view/stable/prologue/standards.html > > What more do you want in BLFS? I'm working on the LSB init scripts now > (mostly from DJ) and will integrate them into LFS. That leaves, at, > batch, and xdg_utils (LFS needs to be updated: coreutils supplies the > test command). Those would be easy enough to add to BLFS. The at and > batch commands are not really needed. I haven't seen them used in over > 10 years. > Actually, I find 'at' to be quite useful for one time jobs...OTOH, I have no idea what batch does. I'll look in a few minutes. > http://ftp.debian.org/debian/pool/main/a/at/at_3.1.12.orig.tar.gz > http://portland.freedesktop.org/download/xdg-utils-1.0.2.tgz Yes, I figure once LFS changes are in, we are very nearly complete for LSB. However, with the new proposals for FHS...
-- DJ Lucas -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
