On 07/30/2010 01:52 AM, Timothy Rice wrote:
> Hi Drew,
>
>
>> How do you like using package users? Have you built anything beyond
>> LFS with package users?
>>
> I think it is just the awesomest idea, I love it. I've got a working base
> LFS system built with package users, and now I'm working on stuff from
> BLFS. My first priority was to get internet access, and I've done that, so
> the next thing on my list of wants is a window manager.
>
Tim, first let me apologize for not reading this until today. You've
really transmitted some great information and expressed some wonderful
ideas.
As far as "window management" goes, I've used Windowmaker since my first
{,B}LFS build--all with package users I might add. And I really like
this manager. It's light-weight and fast. There's quite a bit of
configuring, especially if you want to use a menu system, but once it's
done it's great. The problem that I had with it was that it wasn't being
developed for awhile and maybe in the "functionality" realm it left a
lot to be desired, but it still worked. I checked the other day and
development has started again. I haven't gone so far as to check
releases, but I'm intending on using it in my current build.
> <snipped "package management tradeoffs>
>
> I am also starting to suspect that the main points of frustration with
> package users can be dealt with systematically. For instance, many
> problems seem to arise when one user tries to install files into a
> directory created by another user. It seems to be a valid simplifying
> assumption that all directories created by a user can be made into
> install-directories;
I think that this is the major "frustrator" in this system. I just never
thought of your idea. I do when I want to start a new build generate a
new "installdirs.lst" for inclusion in package users. It heads off a lot
of failed installs. Have you tried scripting it yet? I've got an idea
that might work if you haven't.
1a. for all dir in `forall_direntries_from $ (whoami)`--the experiment
would be to see if this gave only newly created directories.
1b. do
1c. chown $(whoami):9999 $dir
1d. done OR
2. find / -xdev -type d -o $(whoami) -exec chown $(whoami):9999 {} \;
I've not ever used "forall_direntries_from" by itself so I don't really
now what the inputs are or what it yields. Aha, something else to learn.
I do know, however, that the "find" command will work--if the syntax is
right. :) The '-o' option could just as well be '-g' also--maybe use
both to really nail it down.
> only individual files should be protected from other
> users. Now, the process of ensuring all new directories are turned into
> install-directories can be automated. Furthermore, to deal with files that
> all packages should be able to write to, why not construct a centralised
> list of such files. The list can then be checked after each install to
> make sure all permissions are correct, and any corrections can be made.
> This could all be wikified, so that things that work for most people can
> be put into some online location.
>
Ooops. Meant to leave the automation thought before my example.
I'm curious as to what files should be "writeable." What are some of
them that you think should have this ability?
> Finally, I don't think that package users has really come into its own
> yet. At the moment, it can't realistically compete on a large scale with
> systems such as Portage or Sorcery, let alone deb/apt or yum/rpm.
Write now I think that the only "benefits"--which is a relative term for
all but Portage and Sorcery, and I leave those out because I know
nothing about either--is the ability to check for dependencies before
the install and to update scripts and configuration files after install.
For me, I still like to do the latter manually so that I *really know*
what my machine is doing and where to go if there's a problem. Even
using package users, I've never had a dependency problem even on
non-BLFS packages. It's covered in the documentation of the
package--usually.
> However,
> once package users is a bit more mature,[....]
At the very least this will probably mean an update in the hint and
changes to the "Build" script. The hint needs a little polishing now
based on a current LFS-SVN build. If someone (you......me? :) ) were
contemplating this, I think we should contact Matthias and see if he'd
mind. The last change was November, 2005, and I haven't noticed him
respond to anything in a number of years. The hint is not listed as
"orphaned."
> I project that it will leave
> these other systems for dead. An example of what can be accomplished is to
> have scripts that parse the (B)LFS books for source locations and
> dependency information, and automatically download required files and
> install any dependencies, recursively. I know this sort of thing is
> possible because I've seen a java program that will scan the BLFS xml for
> dependencies and generate a dependency graph. It is just a matter of
> having the people with time, interest, and expertise to implement such
> ideas.
>
This sure would be an interesting area for testing--More Control and
Package Users joined with Jhalfs. Whoooooa Nellie!
I have modified the "Build" script so that it finds and untars the
package. It <cd>'s into the directory, does it's thing, makes logs of
all--including tests--and cleans up after itself by removing the source
tree. I still enter all the commands from {,B}LFS with "copy and paste"
to the appropriate sections of the script. Oh, the script will also take
up where it left off on a failed configure, make, test or install.
Tim, thanks for the thought provoking message.
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
