I think Pacman might be a good choice but maybe it would be possible to have chapters for Pacman, dpkg, and RPM, and the user could use the chapter pertaining to his choice of package manager. I think that all three PMs use DESTDIR, so the package manager is transparent to most of the build process. It would only be visible when the PM is used to create the package.
DIY Linux is set up to allow the use of package managers and uses DESTDIR, although Greg does not mandate any package manger. And wouldn't it make it possible to upgrade the toolchain without rebuilding LFS? -------------- Original message ---------------------- From: "Valter Douglas Lisbôa Jr." <[EMAIL PROTECTED]> > Put a Package Management have too stages in my point of view. I create a > infra-sctructure to my enterprise based on LFS, with a package management > included. > > First. The system needs a way to automatize the build and create the > packages, > I think this part can be handled by a external program (nALFS, shell scripts) > who do what the book say to do or create/use a package system capable to auto > create (from toolchain to basic) the whole thing, similar to the portage > Gentoo. > > Second, If the package manager don't auto build the basics, then it will be > essentialy a repository manager. The most packagers in the world do only > this! > > So, before decide between use, not use or create a PM. I think important to > decide what type of aproach is desirable. Like said before in this thread, > write one good package system from scratch is difficult. I start with bash, > but the thing grows very rapid and now I will backport to Perl. Note that I > create a very complex system who split each libso, language dir, command set, > devel manpages, devel files in various packages, to install in the final > system only what is really need! I discourage this approach to LFS and > perhaps use a couple of shell scripts wrapped by a interface tool is more > intelligent. Indeed, the Slackware Package Manager is interesting and I used > it in a primary version, I only abandon because it lacks of dependency > management and I start to store the packages information in a PostgreSQL > database. > > For last, if we create a auto build package system who manage the steps from > the book must likely Gentoo do, perhaps we become a Gentoo like and lost the > spirit of LFS. > > I hope has beed contibuted with something. And congratulations again for the > efforts of all involved in *LFS. > > On Thursday 28 February 2008 05:04:06 Pierluca Masala wrote: > > What about GNU Source Installer? > > It has the following advantages: it is a GNU program, and it leaves > > full control in the hands of the user about configure options and ways > > to build and install. It is focused on installing from sources and it > > also has a gtk frontend that can be used in BLFS systems. > > With this program all the principles and values of LFS are kept, > > because in building packages the details are not hidden and the user > > still has full control over his system. > > You can install software from sources, and then have information about > > the installed programs or uninstall them if you desire. > > > > I'm not an expert about it, but if you don't already know it, you can > > find more information here: > > > > http://www.gnu.org/software/sourceinstall/ > > > > Regards > > > > -- > Valter Douglas Lisbôa Jr. > Sócio-Diretor > Trenix - IT Solutions > "Nossas Idéias, suas Soluções!" > www.trenix.com.br > [EMAIL PROTECTED] > Tel. +55 19 3402.2957 > Cel. +55 19 9183.4244 > -- > http://linuxfromscratch.org/mailman/listinfo/lfs-dev > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
