Randy McMurchy wrote: > You are correct in saying that there really are no guidelines > for the Wiki. It has been assumed that folks will put info out > there that could be deemed helpful to others. If you feel the > info you have is helpful, put it on the Wiki in whatever manner > you feel is best.
Part of the motivation to bring this up was hoping somebody replied with "oh yes, this information would be appreciated." I don't really want to flood the Wiki with things no one's interested in and gets upset about all the noise. >> I'm dreaming of something like a 'database' of all the dependencies and >> a tool that tells you a build order for a specific goal, say 'Firefox'. >> Ok, my little tool was like that, but I neglected to keep the 'database' >> up-to-date. And I used the "as soon as possible" approach only. > > Someone created a Python script a year or more ago that does this > (but only used the dependencies listed in the book). I never used > it, but many said it was a very good script that worked as designed. > For packages that are not in BLFS, but only listed as a dependency, > there is nothing that script could do. You would have to build in > some sort of dependency database as you suggest for packages not > native to BLFS. As coincidences go, my dependency tree creation tool is actually also written in Python. Maybe I should just polish it up a little and try to keep my 'database' up-to-date. [BLFS == distro] > I don't think so, but then that's just me. I only use LFS for > my personal systems. I have over 600 build scripts (with > dependencies noted as comments for the non-BLFS packages) so > 'remembering' things is not an issue. I do the work once, > document it (by creating a build script), and forget about > it. Granted, this doesn't help anyone else. lfsinst:~$ ls bdf | wc -l 652 With about 50 'meta' build scripts in there, I'd call our numbers "close enough" The forgetting doesn't always help here, because some builds change rather severely with versions. > Actually, this is what the Wiki was going to be used for. > And still can. I think you are too hung up about a "template", > or some "proper" way of adding to the Wiki. As far as the > Wiki goes, think Nike - "Just do it". Fine. Hm, am I really hung up about a template? Maybe I am. I'm no fan of hodgepodges, where every Wiki page looks distinctly different than the others. A common style that's followed helps finding the information quickly. Sigh. I'll try relaxing. :-) > As far as package management goes, I suppose we all have our > own methods. I know I have mine. It works for me. That's how > I think BLFS should be. A base where folks can get the basics, > and modify it to suit their own needs. Yes! I have mine, it works for me, too. I made the way I wanted it. But there are still some things common to all or certain approaches. Conceivably there are others using the DESTDIR method of installation. Why should all of us try to find out how it can be best done with this or another package that's not inherently ready for it? It's not too different from the "make check" that is mentioned in the BLFS pages. It could read: Installation into $DESTDIR works. $DESTDIR is called $root_dir, installing into it works except for the man pages. They're best installed manually. For installation into $DESTDIR, you need to patch Makefile.in with http://gloomyworks.org/allmypatches/gloomix-3.14-makefile-1.patch. And hints like: Parallel builds don't work. Parallel builds work fine. Parallel builds work if you do this or that. > I cannot see BLFS *ever* being a book that will be written in > a manner that provides instructions to build a "distro". That > part is left for the user/installer. If that is a hassle, or > undesirable for someone, then perhaps a real distro would > actually be a better choice for them. Maybe I should get my blindfold off, but I can't see the distinction that separates BLFS from a *real* distro. To me, it is one. But maybe your picture of a distribution is different than mine (oh well, that's obvious, isn't it?). It is not the same distro for each of us, but it's doing what distros do on several of my machines since quite a few years. It looks like a duck, it walks like a duck, it talks like a duck. > Hopefully my comments make sense to you, and you see the > reasoning behind my comments. Please feel free to continue > the discussion, or provide additional comments. It is nice > to see someone passionate about BLFS, and I'll see what we > can do to actually use some of the suggestions/ideas. Your comments do make sense, and I really appreciate them. I got the impression that you're a little afraid BLFS might become something that wasn't intended and loses it's identity. Gaining something doesn't necessarily mean losing something else. Now that I've built BLFS a dozen times, I'd like to learn how do get the icing on the cake. Just like with the basic steps, I could use a little help (and hopefully give a little, too). Best wishes, Hans-Joachim -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
