On Sat, Aug 08, 2015 at 07:43:26PM +0100, Hazel Russman wrote: > Chapter 6 of the LFS book deals with the use of package managers. I am > curious to know how any of the ones described would actually work in the > LFS ecosystem. > > A package manager is a tool for automating updates. It therefore > seems to depend on the existence of a repository with the following > characteristics: >
Arguably, package management is a *process* for maintaining a system (in many cases, only for a period of time). Most common tools described as package managers match your comment and I agree that using them on LFS/BLFS lacks your points 1 to 3 below. > 1) Someone keeps it filled with the latest versions of all the > packages, so that the package manager can tell when an update is needed. > 2) For a source-based distro, automated build scripts are also > available. > 3) There is automatic tracking of dependencies. > But for point 3, at least in BLFS (and arguably in LFS where we may ignore dependencies which are not _required_) the book hopes to list all the linux deps. Whether or not any particular person building a system provides the optional deps is up to that person. In my own case I omit some "recommended" deps because they provide no benefits for me (e.g. any package which I build where nautilus or vala is assumed but can be avoided with a configure switch). I'm fairly sure that a few skilled sysadmins have maintained a number of systems based on LFS using rpm or similar by doing the legwork themselves, testing upgrades, and then rolling them out to their users. > It seems to me that none of these conditions are met by LFS, although I > suppose you could use ALFS to fulfil condition 2. > > I must admit, I haven't been updating much, just using each system as a > build host for the next one when a new book comes out, which is > probably very bad practice security-wise. What do other people do? > -- > > H Russman I _try_ to maintain at least one example of each past LFS release until such time as they become too much trouble to maintain. This is specifically for desktops. At one time I was trying to maintain my desktops for three years. Now, I have examples of 7.4 to 7.7 and I probably will drop the 7.4 system once 7.8 is released. Or rather, I was trying to maintain the applications which I actually use, but only to fix known vulnerabilities. But that became impractical (one example I recall was that in the end I could not upgrade to the latest firefox from the previous version because of a compiler problem - maybe it was an early release of gcc-4.7, and fixed in a later point release of that compiler. At that point, rebuilding the compiler was not worth the trouble. And since static compiler libs tend to get linked into many programs, the sensible solution was to discard the system. Similarly LFS-7.3 (I think) where glibc would have needed to be rebuilt. Some people do that, but for an old system only used for comparing how things used to be, and as a potential recovery option if I somehow trashed a newer system, it was not worth the trouble. What I currently do is keep an eye on reliable sites for news of vulnerabilities (in my case, mostly lwn.net). Unfortunately, many new CVEs seem to come up as "Reserved" when a distro announces its own security update. If all the main distros are updating, it is probably a good idea : compare that to the updates which apply to a historic version (debian) where there is probably no need to update. Also, I ensure that updates to openssl and firefox get applied ASAP: first build it on one current machine, check that everything works, and then repeat on other machines and older systems. As part of that I update the certificates and ensure that sqlite, nss, nspr are all using the current versions in the book. For older systems I sometimes have to update other packages (python2 and icu come to mind). For python2, I finally got around to working out which packages install python modules and I now have a script to update those iff I have to update python2 again. But as long as python2 stays at 2.7, and the installed version is adequate for firefox, I do not bother updating it. For vulnerabilities in the perl core distribution (there was at least one in the last couple of years) I prefer to upgrade that specific module - upgrading the perl version is not worth the trouble (too many modules to rebuild, particularly now that I build biber from source without the rolled-up modules in the binary version). From time to time I update other packages, depending on what is in the vulnerability report. Oh, and if you are using BLFS on a portable machine, you should probably also keep an eye on whatever you use for networking. My own netbook now only gets used in my home, so I'm not too fussed about wpa_supplicant or dhclient. I suspect that what BLFS has for wpa_supplicant lacks certain vulnerability fixes from the past year. In the end it is your system(s), your choices. But you do need to create scripts for updating (or scripts for a package manager) if you are not already using scripts. Enjoy the power and the responsibility, and keep your stakeholders happy :) Of course, I'm using scripts anyway to test LFS and BLFS development versions and I now mostly understand how my scripts can fail (I'm now on the 3rd or 4th main revision, I think - with fairly good logging of what gets installed). ĸen -- This one goes up to eleven: but only on a clear day, with the wind in the right direction. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
