Package Management

DJ Lucas dj at linuxfromscratch.org
Wed Feb 27 21:38:59 PST 2008


Jeremy Huntwork wrote:
> Gerard Beekmans wrote:
>> For LFS purposes we first need to determine how far we want to take 
>> package management. In its utmost basic form we can provide commands in 
>> the book to collect a list of installed files before and after the 
>> installation of a package. Compare the two lists with a program like 
>> 'diff', some post-processing to clean up the results, and voila, a file 
>> you can later on loop through 'rm' to remove the just installed files.
> 
> Because PM can be a complex and varied subject, I would suggest that we 
> start small. Start with a POC LFS that employs DESTDIR and a _very 
> simple_ way to package. The two main initial goals might be:
> 

I have to disagree completely about starting small unless your view is 
limited to the current book.  Read Gerard's other post "What if the book 
wasn't a book anymore" and I think you'll see that *everything* will be 
dependent on the PM that is chosen, unless we are still talking about 
the 'book'.  I'm really starting to warm up to the idea of the scripted, 
but interactive installation method.  Sorry to bring up the other thread 
here, but I just don't think we can discuss G's future idea without the 
PM goals completely defined.  I'm also thinking that DESTDIR approach is 
not the right packaging for a source-based distro like LFS is aiming to 
be, though I think it should still be discussed in complete detail so as 
to have justification for the timestamp management type.

My opinion is that it should be an installation tool from start to 
finish.  It should take a file, something similar to a spec file.  BTW, 
we need a flashy name for it and a file extension. How about PackageFile 
for now?  Real creative, huh? :-) That PackageFile should contain the 
following information:
    1.  package name
    2.  package version
    3.  a description of the program
        ##### possibly meeting whatever text requirements we will need
        ##### later for the LFS installation program.
    4.  a list of dependencies/prerequisites
    5.  a source filename
    6.  patches
    7.  sums for patches and source tarballs
    8.  a list of possible download locations
    9.  build commands
        #####  or if we intend to build reusable binary packages
        a. pre-installation configuration
           ##### I think this should include a list of files that
           ##### will be modified so that we can provide a diff for
           ##### use in uninstall
        b. build
        c. install
        d. post-installation configuration
    10. package management (logging of installed *and* *modified* files)
        ##### modified files really are not that difficult to keep
        ##### track of in a timestamp based management scheme,
        ##### just grep through the existing logs for the same files
        ##### that are in the new log...it's slow after a couple
        ##### hundred packages but it works in the most simple way
        ##### until the proposed list in 9a can be populated.
    11. uninstall routine
        a. dependency accounting
           ##### is dependent on whether we are upgrading or removing
        b. removal of installed files
           ##### do we remove configuration files?
           ##### will we need a set of static linked programs to
           ##### handle upgrades of certain libs?
        c. undo post-installation configuration from 7d
           ##### or, use the diffs I suggested to undo
           ##### again, only if not doing an upgrade (I suppose?)
        d. clear package management records of package and support files

Are these the correct goals for the package manager?  Any other 
opinions?  What did I miss?  Is there anything out there already that 
meets these requirements rather than designing a custom utility?  Not 
likely given the text request, but who knows....maybe there is, maybe 
there is a better way to handle the text requirement.  Am I going too 
big and flashy and over complicating things?

-- DJ Lucas




More information about the lfs-dev mailing list