-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

DJ Lucas wrote:
> 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

Don't have a lot of time to comment ATM (working on too many other
things), but I'm leery of this kind of change.  Doesn't mean it can't
happen, but half the point of running LFS (for me) is that I *can* set
it up so that the only thing the PM system does is track which files
were installed by which package.  I don't need it to let me upgrade, I
can do that myself using the script I used to build the thing last time.

That being said:

bitbake does most of what you posted there.  It's used by e.g.
OpenEmbedded as a cross-compiling system, but it might work fine
installing to a normal root directory as well.  It uses .bb control
files, for whatever that's worth.

(In fact, OE is one of the other things I'm working on...)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHxqZqS5vET1Wea5wRA2WwAKDa0bAL/4ZEjmjsdASi+kfYmGmorwCgxumU
Cbwfj1laK8veEo4QShsvVxo=
=smMt
-----END PGP SIGNATURE-----
-- 
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Reply via email to