Bryan Kadzban wrote: > 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?
This whole idea is to show users how to make a 'standard' distro. LSB is not really required if you are building from source. IMO it is really intended as a way to install proprietary binary applications on Linux. That's not something we prefer. LSB is, however, a superset of POSIX and FHS (LSB makes a couple of minor exceptions to FHS). I would like to show users how to make the system compliant and demonstrate tha tit is compliant. >> 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. I agree, but they are applications that are considered 'core' for a Unix system. > 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... :-) Yes, that should be enough, but I need to test it. >> 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. Thanks for reminding me. And thanks to Dan for his input too. >> Couldn't find java > > Bah. Good riddance. Maybe so, but thee are applications that use it. For example, SPSS (now a subsidiary of IBM) makes commercial statistical software that is based on java. If a user wanted to run it on a LFS system, that would be needed. > (Boy, I'm being negative lately...) Not really. It's a good discussion. >> 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. Yes, I forgot. > 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. I agree with your comments, but if someone makes a distro based on LFS, a user of that distro would assume crontab and not fcrontab. A symlink should suffice (plus the man page). >> 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?) If a compiled program wanted to use the time capabilities without bash, then gnu time would be needed. Yes, I believe it was searching the path, but I didn't look at the source. It is a compiled program, but the source should be available. >> <...> >> 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 I didn't check. I installed with alfs and that part of the book is tagged as role="nodump", so it didn't get built automatically. > 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.) Yes, that's my point about making a 'standard' system. I don't want to require a user to install everything, but I want to tell someone building a system what others expect. >> 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. That's why I asked for discussion. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
