On 5/19/12 1:15 PM, DJ Lucas wrote: > What separates LFS from say Arch, Gentoo, T2... at that point? No mile > long USE flags or complex switching scripts I presume, but I know little > about the other two. I've included some of their work in BLFS in the > past, but that is about it.
Well, the way I saw this working out in my head - we don't really advertise the binary package repository, although it would be available for anyone to use. Hence, "semi-public". The focus would still be on the book and letting a user choose her own path. The optional PM parts would serve as a reference for how to do something similar either with the same packaging tool, or one of the user's choice. And yet, in the background, what I'll call the "distro-y bits" would be fully functional, driving consistency in the book(s) as well as accuracy since it should serve to help identify dependencies and installed resources. If anyone chose to actually use the created and shared binaries as a full-fledged distro, they absolutely should be able to, with the knowledge that we are not providing any guarantees as to usability, reliability, or support, etc. > My hope is that build order is still a manual process where the user > determines build order herself. Dependency checking is done only at > build time and that optional deps remain optional. If there will be > automation, how do we determine what optional deps to pull in? I think that can still work. The main point of the "distro-y bits" is to make development easier, as well as provide actual documentation on how to make a binary package distro - not just a system built from source. There's a fair bit more to it than what LFS or the hints provide. > What benefits can we expect for users who have already done the leg work > to use other packaging methods? > For instance, with what is put into the book, could a logical parser be > made to genarate a spec file? How about dpkg? If we did it correctly, I think this should be possible. It would definitely be nice to keep this as a goal. However we do it, it would be wise to make the spec generator modular enough to accept different output filters. > While I admit that the .d/ directory reduces this concern immensely, > what happens to configuration files that must be modified by additional > installations? Do we keep diffs indefinitely, or do we create a comment > marker for each package's additions, modify the package to support some > sort of include directive? I can see scripting getting somewhat > difficult here, not impossible, but difficult. There's two features of most mature package managers that can help with this. First, config files can be identified in the spec so that when the version installed on the system is different than the one in the package being installed, a backup of one or the other is made, and the PM tells you what it did. So this helps preserve user modifications. Second, for config files which we might reasonably expect to be modified by various installed system packages (e.g., /etc/passwd, /etc/group), those modifications can be done through pre- or post-install scripts, as well as pre- or post-uninstall scripts. And yes, using .d directories where supported does help simplify things. > If it is to be done, it should be designed with all goals in mind from > the start. I have long suggested that LFS and BLFS move to installations > from DESTDIR (or equivalent) as this does about 60% of building your src > rpm without defining a particular package manager. The other 40% is just > transposing what is in the book to spec, and could be automated, but > even this has had lackluster support in the past despite the obvious > educational benefits. Absolutely. Looking forward to hearing more thoughts. JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
