> As Debian grows, we need to make sure that our archive concept can cope. It > does fail on several issues already. Instead patching it, we should consider > changing it drastically internally. I think the advantages in future > maintaining are worth the one time pain resulting from a change. > > I agree - I think that now would be a good time to step back from the technical details for a moment, and work out what we want from the archive, a requirements specification. We should consider all the factors, like ports, freezes, mirroring, sections, and 'freeness' and decide what we want, and whether they can be considered to be constraints purely internal to Debian, such as how you find a package in the archive, or external - such as the requirements not to distribute certain parts of the archive in certain countries.
I like the overall pool of packages concept, but I think we would benefit from working out what we want in the longer term, and then creating code in that framework. I believe this is one of the things which makes apt as good as it is - it started with good conceptual framework, and is still gradually filling it out with working code. Conceptually a distribution is a set of packages which are internally self consistent. At the moment we slice our packages up by version number (into slink potato etc) and by target architecture. There are some packages which are arch independent, and largely independent of underlying software versions (the examples I can think off offhand, such as doc-rfc also look like data, but there may be others such as wish or perl scripts which do not require new features of wish or perl) If we can decide on a generic archive format then we could write tools which take complete subsets of the archive which meet certain criteria and use the same tool to write a CD (or set of CDs) as we do to create a subset of the archive for transport in apt-zip style. John Lines