0m3g4_w34p0n at earthlink.net
Wed Feb 27 22:59:55 PST 2008
> 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.
More information about the lfs-dev