> > The other alternative is to stick with a known package manager such > as RPM and thus automatically have all goals provided by it. I still > have RPM instructions from LeafOS, and will check at home whether the > upstream bug about file conflicts is resolved. > Agree with this point. Writing a reasonably good PM is hard, and I don't think it would be good idea to reinvent this wheel on top converting *LFS to be PM-friendly. Everything else in LFS is based around taking existing software and learning to build and make use of it. We should continue this here, pick an existing package manager and run with it.
> OTOH, the need to DESTDIRize the instructions and find out > post-installation steps does exist independently from RPM, so we can > start working in parallel on this task. > > Here is why RPM: > > There are only three families of DESTDIR-based binary package > management system in the world: RPM, deb, and tar-based. A tar-based > system is already suggested. Dpkg requires an enormous amount of > infrastructure just to bootstrap it to a point where the dpkg-deb > --build command works (i.e., produces a package from a DESTDIR and > informational files such as a package description), and that's still > much less than an old-time Debian user would expect (i.e., where the > "debian/rules" files work). > > -- > Alexander E. Patrakov IMO, dpkg is indeed far too difficult to set up, making it a poor choice for LFS. If RPM is significantly easier (really, it couldn't be much harder - famous last words) I have no objection to it. Slackware's PM could also be an option here. I tried it a couple years ago, and it is very, very easy to install. At that point, it did constantly print out warnings that my tar version was too new, don't know if this is still true or not. In any case, we have several options to evaluate and see what meets our needs best. -- Robert Daniels -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
