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

[RFC] Package build time config for installation directories.

I plan on putting together a proposal for this idea I have been toying
around with for quite some time.

Basically we have several problems/issues I want to resolve.

1) Non-FHS ports have problems concering the directories where things
   get installed (they may not match linux directories). Darwin, FreeBSD,
   Hurd and many others fall into this category.

   Current solution: Hardcoded checks in the rules files for Hurd, and
   probably the same for other OS's.

   Problem created: Divergence from a general scheme. New ports have to
   provide new patches to each package.

2) Overlay ports are going to have serious problems. Things like ia64,
   mips64, powerpc64 and sparc64 fall into this category (I gave up on
   sparc64 mainly because of this problem). The reason behind this is
   these ports basically overlay their userspace on 32bit version (or
   will, since not all these ports are ready yet). For instance, sparc64
   puts it's libraries in /lib/64:/usr/lib/64.

   Current solution: None, task is too difficult. Getting all of the
   packages to manually detect a 32/64 port and change the install based
   on that would be a truely daunting task.

   Problem created: These ports will probably never exist for Debian.
   Porters will find it too difficult, or will come up with severely
   one-way hacks to get it working for them, and not for other similar

3) Non-Debian people wanting to use Debian package management and build
   tools in addition to their current OS, have to hand change the package
   files to install things where they want them (/usr/local or /opt for
   instance). Lots of people would use Debian on Solaris if they could
   just rebuild the packages from Debian archives (don't pick on Solaris,
   this was just a grab in the air) and rebuild them with a location they

   Current solution: Users who want this have to hand edit the current
   packages and rebuild, or create their own packages.

   Problem created: Lack of acceptance, and lack of use of the package
   build-tools. The immense resources we have put into our source archive
   are strictly limited to who can use them, and on what system.

Now, here's my solution, and it's very simple. This involves mostly
policy, and lots of package changes. It doesn't really affect the package
manager, nor the build-tools.

Packages would be required to read a file, /etc/dpkg-dev/dirs-i386 for
example, that would list the system directories in this format:


Now, ignore the directory naming for now. Notice the file is in a format
that both sh and make can understand, so this file only needs to be
sourced to get the desired affect. IMO, the directory var naming should be
the same as the auto* packages use, for simplicity.

Packages would then use this to decide where things get installed. Instead
of the package having hardcoded directories for each port, they simply
load in the appropriate file.

Perhaps this could also be handled like dpkg-architecture is now, so dirs
can be queried for. I'm not exactly sure on which way is best.

This would solve all the problems above. Overlay ports could then create
files for libraries to be installed correctly, other non-FHS-compliant
ports could have their special directories, and third-party-OS users could
have their /usr/local setup, just by rebuilding the packages with a
custom directory config.

Thoughts, concerns, ideas?

/  Ben Collins  --  ...on that fantastic voyage...  --  Debian GNU/Linux   \
`  bcollins@debian.org  --  bcollins@openldap.org  --  bcollins@linux.com  '

Reply to: