I've always wondered how you LFS guys managed the programs you installed from source.

Things I've found out by searching through this forums a couple of minutes ago: the package-users management system seems pretty l33t but, frankly, hackish and abusive of the owner:group idea, but sounds a lot like old-school UNIX practice. I've never heard of paco before, but it sounds like it does a lot of things I would want a compiled-from-source packaging system to do and I should give that a try sometime.

I also see that there's some interest in adopting Slackware's pkgtool for use in LFS. This makes a lot of sense since the pkgtool scripts are very simple and will probably work with minimal changes to any other distro.

I have thought of that as well and have been working in the last few days to repackage Slackware's pkgtool for use in other distros, and I'm sure some LFS users would be interested in what I've come up with -- uupt, or universal/user pkgtool.

http://iacs5.ucsd.edu/~pbang/uupt.htm

It's basically makepkg, installpkg, and removepkg from pkgtool, with a simple wrapper script. It's so simple, you can probably rewrite and improve it much better than I can, if you wanted to. =)

But if you want to try Slack's pkgtool on LFS right away, try uupt now and let me know how well it works.

It's all in my head. Admittedly, I do use InstallWatch to make a list of all the files installed by a package. But, I'll bookmark the link and maybe give uupt a try for a package or two.

I really don't understand what you mean by this statement. There is no package management system for (C)LFS except what the (C)LFS user creates or borrows.

Incidentally, you can install and use other distros' package managers too; RPM, APT, Portage, and pkgtool have all been used (so I've been told). But, IMHO, after awhile the (C)LFS system has transformed to something else using one of these, especially Portage. And most (C)LFS users don't want to use precompiled software.

I saw a couple of posts talking about creating a user and/or group for each package you install and managing files through these pseudo-users and -groups. That sounds like an awful lot of work for many packages to me, but, then again, I heard that's how we ended up with '/usr/bin' and '/usr/local' today (with '/usr' initially intended to be what the '/home' directory today is, and early UNIX admins settling on conventions such as a 'bin' user and 'local' user, etc.)

Oh! I don't think I've heard about that one. I think dumb might be a better adjective than "l33t" and it's probably not very widely practiced. I'd agree that it'd be a lot of work! There are several techniques discussed in the (C)LFS books none of which are explicitly endorsed; I think you'll find there's an implicit endorsement of the fakeroot method though.

Not sure dumb or l33t are really words to describe the approach of assigning a user to the install files of a package.

There is hardly any work involved just a matter of either assigning an owner to each file on install or just switching to that user upon install.

There is a lot more effort involved if you install a package that is malicious and wipes your system, and there is more effort involved to provide a separate lookup to work out what files belong to which package.

I retract my dumb. I know what arcanex is referring to now ---> http://www.linuxfromscratch.org/hint...nd_pkg_man.txt. I still think it's a lot of work and don't think the risk/reward ratio is low enough for a single desktop box, but I see the appeal.Really? One line of code is a lot of work? Backup up often enough on a stable system and you won't have many (if any) packages to re-install.Nah. InstallWatch creates a log of every file installed by a package. That's really all you need. I do parse the log with a script to create an XML file that I can view in my always open web browser.

In the end, it's whatever works for you.

The point is not how easy it is to hose your system, but how hard it is to get it back

The code you gave would not hose your system if the user running it was limited, you don't have to use root to install all your files if you install as the user of the package.

Someone had to write installwatch so you cannot discount their effort.

And the effort of scanning that file by the computer system is extra to displaying a file's given ownership.

You can automate the process of assigning users to install, so really the point was it does not introduce extra effort.

That's the command to restore your system, not hose it. Not a lot of effort to fix a boo boo.Someone had to write the hint too.Nothing perceptible to the user though.Which adds to the effort of using this technique.

Like I said, whatever works for you.

Ok, I see what you are saying.

You have to make the backup first it does not magically appear, and of course most working systems will have more than one partition. So, not really one line of code involved at all.

Say an install hoses part of your system you might not detect until after another package install, by then your backup will just be as corrupted.

You would be advised of this complication using the name approach straightaway, though of course you could set the shell to no clobber when installing as well (though that still has less protection).

The backup approach is not without performance degradation in your system, you will be backing up prior to each install and of course you half the available drive size you have.

To be fair the effort required to use the name approach is minimal the only reason I highlighted the effort levels between installwatch is because of this:

It just is not a lot of work!

The problem with using the name approach could appear with group limits in NFS, in which case applying the package name to the group is not advisable.

There is nothing wrong with combining approaches as well, so you could have a backup, installwatch and use the named package approach.

The named package approach just improves system stability on install and speed of feedback on what file belongs to what package.

Having one file contain all the details of the install files whilst taking up more room should respond faster when requesting a list of all files installed, so there is a reason to have another system to find file and package association.

What in the world is this user-based package management supposed to accomplish? I don't get it -where's the benefit?

It helps stop an install nobbling existing files and provides a very quick and simple way to see what package a file belongs to.

I'm using a modified version of pkgtool, too, in my LFS box. It's so easy.
I've enhanced it with a "buildpkg" script that is really powerfull to install or fake-install one or many packages in one go.
It's working good but, currently no help is available and I have no place on the net to hold the stuff

smurth, have a look at this:
http://distro.ibiblio.org/pub/linux/...migo-PkgBuild/

Sorry, I have no time to completely look at it... and my "buildpkg" script actually do want I want it to do. I'm adding new features as I need them.
It's a very simple but really powerfull tool.
I'm taking my time to build my linux box. It takes me months to do what could be done in one week. But I'm taking pleasure with this all.
When I'll have some time, I'll try to release my modified version of pkgtool, including my "buildpkg" script; but if someone wants to play with it now, just drop me a line at "smurth at free dot fr"