MySQL and "More Control/Package Users" Package Mgmt

Timothy Rice t.rice at ms.unimelb.edu.au
Sun Jun 20 15:31:09 PDT 2010


Dear BLFSers,

First of all, some background. I am currently working from the BLFS
development book. My base LFS system was constructed according to the
version 6.5 lfs book, conforming to instructions as closely as possible. I
am using the "More control and package users" (MCPU) package management
system [1], and am having problems installing mysql-5.1.42.

In accordance with MCPU discipline, I have a package user called
mysql-5.1.42 belonging to the mysql group.

My build process is to first run the following script as root if this has
not been done before:
http://ms.unimelb.edu.au/~trice/pre-build

Then to exit root and run the following as user mysql-5.1.42:
http://ms.unimelb.edu.au/~trice/build

As you can see in the following logs, the "configure", "make", and "test"
steps all work correctly:
http://ms.unimelb.edu.au/~trice/{configure,make,check}.log

(While it's true that a couple of tests failed, the most glaring seem to
happen simply because my lfs isn't yet able to access the internet; none
of the tests caused the build process to abort.)

Then we get to (the tail of):
http://ms.unimelb.edu.au/~trice/install.log


It appears that mysql would like to rm a file that it isn't supposed to be
playing with, namely some file called 'dir'. However, the install log
isn't explicit about the location of this file; nor does the mysql
documentation seem to explain why this file should be removed in the first
place.

Annoyingly, whether I respond yes or no (to whether the file should be
removed), the install fails at this point without issuing a final error
message explaining what went wrong.

To get a list of candidate 'dir' files that mysql might be interested in,
I ran the following command:
find /{bin,boot,etc,lib,opt,sbin,srv,sys,tmp,usr,var} \
     -regex ".*/dir$" -exec ls -l {} \;

The following output obtains:
-rw-r--r-- 1 root root 82706 2009-12-08 12:13 /usr/share/info/dir
-rw-r--r-- 1 guile-1.8.7 guile 811 2010-05-08 14:34 /usr/local/share/info/dir
-rwxr-xr-x 1 coreutils-7.4 coreutils 351940 2009-11-30 14:51 /usr/bin/dir


Now, I can't think of any reason why mysql should want to remove any of
these files. It could be argued that I should therefore delete the
offending command from the mysql makefile(s); the latter, however, are not
entirely transparent. Ideally, it would be good if I could put something
in my build or pre-build script that would circumvent the need to modify
any makefiles.

So, what I would like, most importantly, is to know the reason (if any)
why mysql might be wanting to remove any of the above files.

Secondly, suggestions for workarounds that don't involve installing as
root would be much appreciated.

Something that just occurred to me while writing this email (but can't
implement at the moment since not at my home computer) is to back up each
of the files to somewhere safe, change the originals' permissions to 777,
and see what happens. If I don't like what mysql does, I can copy the
originals back in. This seems a bit of a hacky way of proceeding, however.
Thoughts?


Thanks for your time and of course let me know what additional information
you may require.


Cheers,


Tim



[1] For the unfamiliar, MCPU attempts to hermetically seal packages from
each other by avoiding installs as the root user. Instead, each package is
assigned a user in an "install" group; the install group has write access
to all the standard install directories (/usr, /bin, etc.) This write
access is made sticky so that packages cannot modify each others' files.

This is generally a good thing, but requires some work-arounds in
situations that really do require packages to modify files that belong to
another package. For more information, see the "More Control & Package
Users" hint on the lfs website.





More information about the blfs-support mailing list