Re: Proposal: incremental release process (the package pool)
> 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
Reply to: