Re: smarter way to differ architectures needed?
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
philipc@copyleft.co.nz - prefered. philipc@debian.org
Reply to: