On Sun, 4 Mar 2001, Marcus Brinkmann wrote: > When you read http://master.debian.org/~brinkmd/arch-handling.txt, you will > find out that my imagination on this has virtually infinite dimensions, not > two or one. > > The truth is that the two dimensional view on this (CPU, SYSTEM) works well > for autoconf and compilers, but still does not scale good enough for complex > packaging systems. In the above article, I try to advocate a much more > flexible way to think about architectures, based on the *interfaces* the > architectures provide. >
I took a good look at arch-handling and I found it good and useful as it got me in touch with the issues, thanks. >From the point of view of someone who maintains a partial mirror and produces installation CDs, both standard and vendor, I would like to see scoring incorporated into "installations" rather than "distributions" for the following reasons. There are 10+ Debian mirrors in New Zealand, all of them partial mirrors and most of them are i386 binary only. Most of these would expect a wide variety of ix86 systems to point apt at them and install packages. In all probability the people doing the installations should have no idea of the subset of i386 they should be installing. This means that 1. the mirror would have to have all i386 and 2. apt would have to be able to inform the the person installing of scoring and hints. As a CD vendor my Debian customers are Debian newbies, after a few months they discover what apt can do and don't buy another CD set. These customers will have no idea of the subtleties of any subsets and again all of i386 (sparc or whatever) would have to be included. It would be up to apt to inform the operator of scoring and hints. I hereby drop my "Platform:" proposal. I put my weight behind the *_SYSTEM-CPU.deb for all binary packages, including *_linux-CPU.deb. This would make mirror management much easier. I must take a look at some Linux-i386 mirrors and see how many of the are inadvertently mirroring the Hurd in pool. This kind of situation makes for unhappy ftp-masters when they find out what has been happening. As someone who builds Hurd CDs *-all.debs are a pain. At the moment I have to guess which are relevant when it comes to building the second (extra) CD. I wonder how the people who create the Packages file are coping. Footnote. I have a horrible feeling that at some stage it may nessesary to differentiate source as well as binaries. gnumach_1.2.orig.tar.gz? Phil. - Philip Charles; 39a Paterson St., Dunedin, New Zealand; +64 3 4882818 Mobile 025 267 9420. I sell GNU/Linux CDs. See http://www.copyleft.co.nz [EMAIL PROTECTED] - prefered. [EMAIL PROTECTED]
