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 ports. 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 want. 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: libdir=/usr/lib syslibdir=/lib bindir=/usr/bin sbindir=/usr/sbin sysbindir=/bin syssbindir=/sbin mandir=/usr/share/man x11bindir=/usr/X11R6/bin (....) 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 \ ` [EMAIL PROTECTED] -- [EMAIL PROTECTED] -- [EMAIL PROTECTED] ' `---=========------=======-------------=-=-----=-===-======-------=--=---'
