> From: Paul Rogers <[email protected]> > Date: Tue, 31 May 2016 16:30:46 -0700 > Subject: Re: [blfs-support] Dependency chain > > > > > (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.
You're responding in sort-of digest-mode, in the above; further, it's not clear which person(s) you're responding to in each chunk - you've stripped out most of that info. How about responding in threaded-discussion mode? rgds, akh -- -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
