Hi,
This list is very quiet and I am always glad somebody share ideas on it.
Let me add some comments interspersed in your mail
On 30/03/2016 17:02, Roger Koehler wrote:
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.
Actually, Bruce himself says he rebuilds almost any new package on top of
the old one. For glibc, this is harder, because while you install the
new glibc,
the old one is destroyed before the new one is able to run. So you loose all
your utilities (cp, mv...) and the system is broken...
But having package management allows to do that more cleanly.
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!
Sure!
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.
I had to choose one for jhalfs, and I had already used dpkg
manually. Furthermore dpkg does not have too many dependencies.
But yes, dpkg is picky about overlapping files. Since then,
I've heard about porg by Fernando, but have never used it.
A2) Porg!
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
replace them:
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.
I'd say it is just enough... Once you tick "package management",
the system generates instructions for DESTDIR installs, and the
packInstall function (from packInstall.sh) is called. This function
is expected to perform the necessary steps for packing the
DESTDIR directory and install it. Of course those steps involve calling
the package manager, which has to be available at the beginning of
chapter six (so it should be built at the end of chater five, but just what
is needed for packing and installing) and then build the whole package
at the end of chapter six.
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.
I'd say it is not needed, unless porg is very different from other
package managers.
SUMMARY:
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!
How long... Depends on you ;-) I mean I am not able to work on this
myself, because I have too much else to do (with updating BLFS
+ real life job). But I'd be happy to follow what you do and give some
advice.
Regards
Pierre
--
http://lists.linuxfromscratch.org/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
