On Tue, May 31, 2016 at 04:30:46PM -0700, Paul Rogers wrote: > > > 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. >
In html ? > > 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. > I was making a general point, not specifically asking you ;-) I'm sure you could do it, but I'm really interested in persuading anybody who thinks they could do it. And they probably need to read most of the posts on the list, so mentioning it in an unrelated thread seems reasonable. > > 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". > For databases - unless you need one for your own use (in that case, I would recommend postgresql although I haven't had time to use it for about 2 years, so help me Codd) then only install the minimum. Sqlite is commonly used by other packages. But I think you can forget about hal - unless you move to a BSD. > > 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. > I think we're stuck with both for the moment - except for those people who use Python for scripting, neither is useful in itself to an end-user, but both are used by various things which we might want. Distros such as, ISTR, fedora, and also gentoo, have tried to move to python3 but a lot still needs 2. If my memory is correct, Igor tried to move to 3 last year but found things he used which needed 2. And for both python versions, the fun part of system maintenance is keeping track of which packages installed python modules, so that you can rebuild those if you have to upgrade that version to a new minor [ I recall having to upgrade python2 once so that I could continue to compile firefox on an old system[1], and I think there have been vulnerabilities since then which were best addressed by upgrades ]. [1.] That was probably a move from 2.6 to 2.7. These days, I cannot build firefox on my old gcc-4.9 systems, so I guess I have now given up trying to keep my old BLFS systems usable. At least that cuts down the rebuilds every month ;-) ĸen -- I had to walk fifteen miles to school, barefoot in the snow. Uphill both ways. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
