Re: smarter way to differ architectures needed?
On Sun, Mar 04, 2001 at 05:14:00AM +0000, Philip Charles wrote:
> >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.
Brian May wrote me the same privately, and I give in. It makes sense to
provide a subpool of all installable packages (regardless of their score).
But we also need the distribution with maximum score packages only.
Remember that apt is an optional feature built on top of dpkg, and we should
provide a simple solution for people not wanting to deal with a full pool of
packages to select from.
So, I will adopt my proposal (when I have time) with this scheme:
Pool (all packages)
-> i386 Sub Pool (installable packages) -> i386 Packages file -> dpkg
\-> apt (\-> apt, too!)
-> i486 Sub Pool -> i486 Packages file -> dpkg
\-> apt
-> hurd-i386 Sub Pool -> hurd-i386 Packages file -> dpkg
\-> apt
...
All sub pools and Packages files are "virtual" (only refer to the pool
packages).
> I put my weight behind the *_SYSTEM-CPU.deb for all binary packages,
> including *_linux-CPU.deb.
That's not what I meant (but I am afraid I am not understanding what you
mean with this syntax in the first place). We will still have to deal with
binary all, hurd-all and linux-all packages in the workarounds currently
proposed.
> Hurd in pool. This kind of situation makes for unhappy ftp-masters when
> they find out what has been happening.
Really? There are scripts to mirror only the packages listed in a list of
Packages files.
> 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.
All -all packages should be relevant. If they aren't, they should be
linux-all. That's exactly the thing we want to kludge around for now.
> 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?
Ah, that's something we didn't talk about yet. Thanks for the heads up.
Luckily it is quite easy. There are two ways to look at it:
1. Debian as a whole has all sources in one big pool for all architectures.
Works fine.
2. If you only want the sources to your binary selection, you make the
binary selection and get the source for just these binaries. The package
and source files provide the information necessary to determine this.
So, for sources, it is either bottom up (build all binaries from these
sources, and get them into the right place), or top down (select binaries
you are interested in, get the sources corresponding to them).
It is very interesting to hear the opinion of someone who actually does
mirroring and distributions, it pointed me to some problems (but nothing
serious yet, IMO). I will include the results in my article.
Thanks a lot for that.
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
Reply to: