> > (IOW, the real central issue is that the raw dep-logic is, as noted > often(-ish), not a simple tree or even a DAG.) > > rgds, akh
Thanks. They don't call it "dependency hell" for nothing. I spent weeks, part time, trying to plan my 7.7 install for the right order of things before I started. I got there, but it still could be improved. > I suspect you actually want the reverse: "Packages in the book which > can use this package". I'll tell you now, it ain't going to fly. What I was asking about is a "doubly-linked list" as Bruce suggested. > I repeat - what we really need is more editors ... > and (critically, in the light of the last year) an ability to work > with other editors without denigrating them. I had a pretty good reputation for calm reason in the face of typical flames over on Galaxy Zoo. My Asperger's means my emotional responses are generally subdued. I could logically explain to overly excited newbies that the presence of a SMBH in one galaxy wasn't going to suck every other galaxy in sight into its maw. > Also, at a minimum the current release of LFS and BLFS. Having spare > time and a fast machine also help. Not so much interested in the first, retired but somehow not overendowed with the second, and mostly using Conroe E6700's, only one early i7-940 quad-core "compiling engine" box, so not much of the last qualification. > For your problem - start with the applications you want to have, work > out their dependencies iteratively until you get back to base LFS. > Then come up with a sequence (build order) which suits what you are > doing. And expect to change that order from time to time. I do, but in doing that 1) sometimes one needs to know what was depending on this package that now may come out, e.g. HAL, and 2) to make a choice among, for example, say databases to install, it helps to know how many and which other packages it will support, so to minimize the "duplication". > e.g. I saw a report on the Mesa list that Python3 will be required Case in point. I'd like to avoid the necessity of supporting both 2 & 3. Sure, I *can*, but it's hardly optimum. > Note that he's not asking for any information that isn't already in > the book - if Firefox can list a dependency on Gtk3, then we know that > for Gtk3, Firefox is a package that requires it. I can't see that it's > a huge ongoing burden for editors So it seemed, from the outside. But I've worked with the books enough to recognize the amount of work that they save me, which must have come from somewhere! ;-) > - but it does require a bunch of clever scripting to automatically > generate the reverse-dependencies from the dependencies, and to > incorporate that into the book. pio, my package manager, allows me to tag each package with its requirements (building and runtime), and I have scripts that convert that into a list with forward and backward pointers. But I don't necessarily add all the optional support. > And yeah, I agree it would mostly be waste space in the book. I don't > see the use-case for it... what's the benefit in looking at Gtk3, and Did I demonstrate that above? > seeing a list of some dozens of packages that I can build once I've > installed that one? Not a great example, to be sure. Let's take the databases though. Several places one can choose, then the question is which one can support the most other stuff and which are stuck with only one or two-- how to minimize. > I had a similar question as Paul, where I wanted to know which > packages depend on a particular package. Yay! > At the same time, I understand that this becomes too much work for the > people working on updating the book and, for what its worth, I also > think it is does not add much value in the book. I could agree if all one is considering is getting from LFS to an enhanced system, the one way trip, and one isn't particularly interested in maintenance. I think it's a special kind of information that is mostly useful when it comes to making an optimized (in some sense) system and maintaining it. > So, I ended up creating a small Python command line utility that could > scrap the data from the book and give me such a list. I think I'll give it a try. (Especially since I've just decided to rebuild my 7.7 system as 32-bit also.) Thanks. -- Paul Rogers [email protected] Rogers' Second Law: "Everything you do communicates." (I do not personally endorse any additions after this line. TANSTAAFL :-) -- http://www.fastmail.com - A fast, anti-spam email service. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
