Roger Koehler <roger.o.koehler <at> gmail.com>
2016-03-30 15:02:24 GMT
Kudos to Pierre! I am impressed with your work on package management in Jhalfs.
I just have some thoughts I'd like to share (if anybody ever reads this list):
Q1) Why would any LFS user want to use package management?
After all, according to the book, for any update in LFS (especially
Glibc), it is recommended that the entire LFS system be rebuilt (which
Jhalfs makes very easy, but it is still time consuming.
A1) To make the build faster!
For every package that DOES NOT need to be rebuilt, DON'T REBUILD IT!
Install the binaries that you saved instead!
In my opinion, package management can do for Jhalfs what Jhalfs did
for LFS -- make it much faster!
Q2) Which package manager would be best suited to satisfy this requirement?
Peirre seems to have settled on Debian's dpkg, but he has provided an
example for pacman as well. I don't know anything about pacman, but I
have enjoyed the ease of building a Debian system using dpkg, alt,
aptitude, and synaptic, and I was very impressed with Peirre's dpkg
solution in Jhalfs. I was so impressed in fact, that I tried to use it
to build some custom packages as well as the blfs_root dependencies.
This is where it bombs and requires more work than should be
necessary. I thought about converting all of the books instructions
into control scripts -- except for the actual binary tarball, but then
other issues are encountered. For example, dpkg complains when any
packages (such as Python2 and Python3) overlap.
If all that is desired is to make the installation of an LFS system
faster, porg (see http://porg.sourceforge.net/) is the way to go! Its
one line stated purpose is "to aid management of software packages
installed from source code."
Q3) How should it be implemented?
How can porg be used to make the installation of an LFS system faster?
A3) Only use it where "make install" or similar easily replaceable
instructions are found in the book.
... or in packages that use different build instructions but take long
enough to build to justify creating extensive xsl instructions to
Simply search for an archived porgball that matches the version of the
package in the book's instructions. If it matches, use the porgball.
If it doesn't, build a new porgball first, then use it. Then take care
of all the necessary configuration as usual.
Nothing fancy required, and the benefits would be amazing!
Q4) How should it be implemented?
I am planning on using Pierre's example packageManager.xml.dpkg and
packInstall.sh.dpkg files to create porg versions to start, but this
would just create the packages.
A4) Create new LFS.xsl and master.sh files, and put them in the pkgmngt folder.
Also, change the function of the PKGMNGT configuration parameter to
use the new LFS.xsl and master.sh files.
What do you say, Pierre? How long would it take you to implement this
solution? I'm sure you are much more qualified to do this than I am,
but I'll plug away at it and see how far I get with my limited time
and know-how. I'm sure I will learn a lot in the process, but I will
happily throw it all away when your solution becomes available!
Thanks for reading,
Unsubscribe: See the above information page