Upgrading software?

John Gay johngay at eircom.net
Tue Jan 14 08:36:03 PST 2003

On Mon 13 Jan 2003 05:28, Dagmar d'Surreal wrote:
> On Sun, 2003-01-12 at 20:43, John Gay wrote:
> > I mentioned this in another E-Mail, but got no feedback, so I'm posting
> > the idea again.
> >
> > I was wondering how difficult it would be to set-up a sandbox-type setup
> > for testing software upgrades before installing them permenantly?
> This depends entirely upon how much effort you're willing to invest in
> doing it.
Ian gave me a very good run-down for accomplishing this.

> > I am planning to build a full desktop with my Daughter from scratch once
> > KDE3.1 is released. However, I notice that things are updating all the
> > time. For simplicities sake, I'll be sticking to the stock 4.0 install
> > and the BLFS from October, since that is what I based my dependancies on.
> >
> > However, I would like to be able to test and upgrade so her system does
> > not become dated.
> >
> > Would it be possible to install an updated package in say /usr/local/test
> > and verify that it works with everything before installing it in /usr
> > directly?
> Very... although it would not be safe to try copying the files from
> /usr/local/test into /usr due to the tendency of many applications to
> hard-code paths.  It would more than likely be easier for you to just
> keep the source code for the package handy somewhere, and instead of
> typing in the commands to build and install it directly, write a short
> shell script to do it, so that you can just change --prefix=/usr/local
> to --prefix=/usr when you feel certain the new package works properly.
Well I did plan to re-compile everything for the proper install after the 
testing went well.

> > Also, for KDE, I was planning to install this in /usr/kde3.1 and provide
> > sym-links to /usr/kde so that when I upgrade, I can install in
> > /usr/kde3.2, test it out, and then move the sym-link. Is this practical
> > and good practice?
> Only you can decide whether or not it's practical, but as to whether or
> not it's a good practice... it's not specifically a bad practice, unless
> you count deviation from the FHS (which is neither perfect nor
> all-seeing) a bad practice.
Well, I don't want to drift too far from FHS, but this seemed like a good 
compromise. I want KDE under /usr, as I'm building it as part of the 
installed software, but I want the flexability to test and upgrade as well.

> > On a more complex area. Linus tells us that /usr/src/linux is reserved
> > for the kernel sources that glibc is built against, not the kernel of the
> > day. However, what about when I want to update glibc? Should I install
> > the latest kernel sources into /usr/src/linux, then re-build glibc before
> > re-compiling the kernel so that they match?
> I think you may have mis-read something.  Afaik, glibc never reads
> anything under /usr/src/linux, and /usr/src/linux has historically been
> a symlink pointing to /usr/src/linux-x.x.xx source that's currently
> being used (several other packages do look in there for clues when they
> compile).  /usr/include/linux and /usr/include/asm*/ on the other hand,
> are supposed to be copied from the kernel source that glibc was built
> using, and kept there until glibc is next upgraded.
Quoting from linux/README:

   Do NOT use the /usr/src/linux area! This area has a (usually
   incomplete) set of kernel headers that are used by the library header
   files.  They should match the library, and not get messed up by
   whatever the kernel-du-jour happens to be.

And I read a further clarification from Linus stating that this was to 
maintain symbol campatibility for glibc. In other words, glibc is compiled 
against the kernel headers, and quite often other packages reference kernel 
headers. The have to match, therefore the kernel headers in /usr/src/linux 
MUST be the kernel headers glibc was compiled against or you could end up 
with unresolved symbol problems.


	John Gay
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-support' in the subject header of the message

More information about the lfs-support mailing list