[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Modifying Debian for Infrastructures--Step 1

On Wed, Feb 16, 2000 at 05:18:32PM +0100, Bud P. Bruegger wrote:
> o    will this approach work?  Is there something we didn't think of?

(1) references to existing material which is used in the build
process.  You might have already solved this.

(2) some systems never refer to the entire path.  Dummied up example:

	install whatever $(INSTALL_ROOT)/bin/.

(3) sometimes the relationship between different parts of the system
(relative path for symlinks, perhaps) is a tacit assumption -- if you
change this, things could break.

(4) sometimes there are hardwired assumptions about path lengths --
if you change the length of a path there are some pieces of software
which that could break.

> o    which are the path that have to be substituted?  Where is the
>      Debian doc that lists them all?

Substituted for what purpose?

While we've not yet fully adopted the standard, we're migrating to the
FHS which is supposed to be designed for multi-architecture filesystems.
I believe that for this case the /usr/share/ hierarchy can be re-used
across architectures (for the same package version) while the rest of
/usr is considered architecture dependent, and /etc is considered local
machine config.  But that's not been exercised yet, and we have no dpkg
support yet for this concept.

If I understand what you're saying, the simplest mechanism would be to
use dpkg --unpack --root=... to bring the various package versions onto
the machine then play with symlink farms to do package configuration and
to use the packages.  Brute force, and dead stupid, and you'll have to
deal with propagating renames of symlinks across to the original files,
but it seems doable.


Reply to: