Upgrading software?

Dagmar d'Surreal no.spam at allowed.here
Sun Jan 12 21:28:54 PST 2003


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.

> 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.

> 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.

> 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.

-- 
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