Bruce Dubbs wrote:
> The problem is that there are several package management schemes and 
> they are generally incompatible.  They are also targeted towards binary 
> installs.
>
> When discussing PM, we first need to agree on the goals.  What are we 
> trying to do with it?  Install an upgraded package transparently?  Keep 
> track of files on an LFS/BLFS system?  Uninstall a package?  The only 
> practical way I can see for doing any of that is to have a separate 
> application do the work.  At that point we are fundamentally not doing 
> it "from Scratch" any more.  It may as well be Gentoo.
>   
I think there is a spectrum of possibilities with the current LFS/BLFS 
at one end and Gentoo at the other.  Gentoo is for someone who, say, 
wants to run a MediaWiki server and tells Gentoo "I want PHP" and Gentoo 
responds with a list of 200 ebuilds that are needed to achieve that.  
The person may have some input into the process like choosing Postgres 
instead of MySQL in the USE flags, but once that's done the build and 
any upgrades are fully automated, and require relatively little thought 
from the user--unless he likes to start tweaking things (and that may 
lead him to consider LFS :-).

The current LFS/BLFS instead requires that the user follow a manual 
procedure to arrive at an equivalent, hopefully better result.  The base 
system is essentially dictated by the book, while the BLFS packages 
require knowledge or research into what is to be built (although someone 
could build everything blindly).

As I see it, the issues begin when package upgrades are released and the 
user wants to install them.  Unless he scripted the original build and 
kept a record of the installed files, he may be reluctant to apply the 
upgrade.  And of course, some packages cascade onto others.  And if 
glibc has to be rebuilt, the only recommended solution is to rebuild 
*everything* from the beginning.

Some editors and community members obviously don't mind rebuilding 
everything every three months or more often (and must have developed 
scripts to assist in that task), but I suspect other LFS users upgrade a 
few top level, daily use packages often and leave the rest alone until 
really necessary.  At that point, I think a minimal PM that at least 
allows review of what is about to be installed (outside of the build 
tree) and ideally provides a means to undo a faulty installation (even 
if manually) would allay the fears of updating a package that may be 
critical to the user's system, but doesn't get much of his attention.

Joe
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to