Bruce Dubbs wrote: > I've been looking at LSB and in running a couple of basic checks find > that we have some missing libraries and programs in LFS/BLFS to get > to compliance.
Surprise. LSB is by *no* means minimal. Neither is LFS, of course, but when you require a specific package manager to be installed and presumably usable (that means dependencies have to be there), that's past what I want to work around. Especially when it's RPM. Of course, RPM is available in BLFS I think, so we technically have this already. But it's the kind of scope creep that I hate. They already have this giant list of programs and interfaces that are supposed to be present; why not just use those to install a package? > Couldn't find at > Couldn't find batch Meh. I suppose if the admin wants an at daemon. I'm not convinced it should be required by random software packages, myself. If somebody's installer -- or worse, program at runtime -- tries to create an at job, that seems to me like a broken installer (or program). The contents of at (and cron) configs are *mine*, not some random other package's. If a package needs an at job, then (1) why? what on earth is it doing? and (2) tell me; I'll decide if it's OK. Don't just go and add a job yourself. But then, this might just be a case of me using LFS because I think this way... > Couldn't find crontab Link to fcrontab had better suffice, see below... :-) > Couldn't find install_initd See bootscripts/contrib/lsb-v3 in the book repository for this one. Personally, since I never use this interface (since symlinks don't confuse me :-P ), I don't want it, but... Note that I believe it also requires either symlinks, or moving all the bootscripts around -- /etc/init.d/, /etc/rc?.d/, etc. not all those same paths under /etc/rc.d/ where they stay out of the way of /etc tab completion. That may not be a strict LSB requirement, but I think I remember DJ talking about it at one point when doing the lsb-v3 thing. > Couldn't find java Bah. Good riddance. (Boy, I'm being negative lately...) > Couldn't find remove_initd See above re: bootscripts/contrib/lsb-v3/ > Of course, several of these are in BLFS, but many are not: xdg-utils, > pax, cpio, at, batch, and gnu time jump out as being needed. ISTM that (if people that have actually done BLFS dev work -- i.e. not me -- want to...) xdg, pax, at, and batch, at least, belong there. (*Especially* if xdg requires a bunch of GNOME base packages. Like, say, gconftool-2, which I see in at least one of the scripts. :-P ) For at/batch, I think this for the same reason that cron is there. I should note that cpio is already in BLFS. Since pax is a third standard trying to displace both tar and cpio (SIGH: you can't stop people from arguing by shouting overtop of both of them; you likewise can't stop a standards fight by proposing a third standard), there's even less of a point to putting this in LFS, I think. > We have fcron, but I'm not sure if we need to create a link from > fcrontab to crontab or if Vixie cron is required. Not having read the standard at all, I don't see any particular reason to require a specific cron implementation. The whole point is to provide an interface so that $random_program_x written by who-knows-who (and not, mind you, autotooled or using the Loki installer or anything like that; likely not even open-source, although I don't mind so much about that one) can run the right programs to do things. I don't see why a program other than my shell should ever be running crontab. As I said above, the contents of the cron config files are mine. > Should we be installing some of these (e.g. cpio, pax, Gnu time) in > LFS? Hmm. All of the below are my opinions... cpio, no. Nothing uses it except rpm (and see above about that one). pax, also no. I touched on this above, but for the same reason I say no to cpio: why support a crazy weird format that almost nobody uses, unless it's required by something the user is doing? :-) See also the comment above about proposing a third standard. GNU time, *also* no, unless I have the wrong GNU time. Isn't it exactly the same as bash's "time" built-in? http://www.gnu.org/software/time/ Unless that's the wrong package. Do you know why the LSB test thingy didn't find the bash builtin on your system? (Was it searching $PATH manually?) > <...> > Of course most of these are in BLFS, but I'm concerned about > the libncurses requirement. In LFS we install libncursesw. Ubuntu > has both. Should we install both in LFS also? Don't we? The book shows "symlinks and linker scripts" being created to make this happen: http://www.linuxfromscratch.org/lfs/view/development/chapter06/ncurses.html Of course that only works with programs that get compiled anew -- but see the note at the end as well. (Personally, I dumped those libs into /usr/lib/ncurses-nonwide so I knew when I was trying to run a program that couldn't use wide-character curses, and could use LD_LIBRARY_PATH to make them work, but that's mostly irrelevant.) > We install jpeg7 in BLFS. We used to install jpegsrc.v6b.tar.gz > which gives libjpeg.so.62. I'll investigate to see if we need both > versions. As long as it's optional, I suppose. Otherwise every jpeg release is going to require the older versions as well, since the devs apparently like to break binary compatibility. (That *is*, after all, the point of creating a new soname: to explicitly break compatibility. If you need the old soname for the next six years for LSB -- assuming they deprecate libjpeg.so.6 *today*, and moved to 7 -- then you need the old package.) > What I want to do is to introduce LSB in the Preface of LFS and then > continue with more discussion in BLFS "After LFS Configuration > Issues". In the appropriate packages, add a comment that "This > package is needed for LSB compliance." I some cases there are > definite alternatives. For instance the sendmail requirement can be > met with any of the MTA packages in BLFS. Yeah. Noting which programs are needed wouldn't be too bad. Moving a lot of them into LFS, I wouldn't like. Most of the stuff you mentioned is pretty rarely needed in reality -- or at least, on my system, which is mostly all I care about. Obviously this is a bit of a skewed perspective though. :-P
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
