Bruce Dubbs wrote: > Bryan Kadzban wrote: >> 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.
Right, but even for the case of installing binary applications, they don't need to dictate RPM. (Or any other package format.) They can build on the fact that they've dictated install, cp, mv, touch, etc., and have the program's installer use those. But, whatever. >> 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. Maybe. Hmm. Then again: I need to keep telling myself, "it really is optional". :-) >>> 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. Right; but in my ideal world (which, mind you, probably doesn't actually exist :-P), the program itself would tell you that it needs java -- say, in the place where you download it -- and you can go find java yourself. I suspect, however, that simply indicating "this package is required for LSB" on the jdk page in BLFS will be sufficient. I think this is what you were planning anyway. :-) >> 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. Hmm. Yes, exec()ing /usr/bin/time (or whatever) requires that file to be present. (OTOH it could just be a script, like one of the variants of which in BLFS.) But as for java above: a note would, I think, be fine. >>> 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: > > 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. Oh, I see. I -- perhaps obviously -- did it manually. Part of this was because it was multilib, and I didn't want to do full CLFS, so I was manually hacking together some things from DIY and some things from LFS, and reading both. But that makes sense. >>> 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. Yep. Fair enough.
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
