[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bits (Nybbles?) from the Vancouver release team meeting

Steve Langasek wrote:
> > How is the layout of scc.debian.org planned to look like? Separate
> > <arch>.scc.debian.org (or scc.debian.org/<arch>/...) archives or a
> > single one which needs partial mirroring tricks? Will arch:all be
> > duplicated there or will it need to be fetched from some other mirror?
> I don't know the details of what's currently planned for the mirror layout.
> I know that per-arch partial mirroring was a goal at one time, but AIUI
> the current thought is that a two-way mirroring split should be enough to
> start with.  I don't know the reason for the change, although I suspect that
> a per-arch mirroring solution, accessible to mirror operators with limited
> toolkits while not causing needless data duplication, is a difficult set of
> requirements to code for.

Hm, splitting the pool in source/all/arch1/arch2/... has no drawbacks
I see immediately. For mirror operators it would mean just a few more
rsync lines. The obvious problem is to adapt the archive scripts, I
hope it would be a smaller task than the introduction of package pools

Such a layout would also help for the mainstream architectures,
especially when taking the multiarch future into account. A mirror
admin only interested in Apple hardware could easily mirror powerpc,
ppc64, and i386 (for emulations), without much rsync fighting to get
rid of all the pieces for amd64/ia64/whatever. Currently, the attempt
to exclude arch-specific stuff in dist turns the mirror script into
a mess.

The master archive would then be ports.debian.org, with an layout of

`-- debian
    |-- all
    |   |-- dists
    |   `-- pool
    |-- arch1
    |   |-- dists
    |   `-- pool
    |-- arch2
    |   |-- dists
    |   `-- pool
    |-- archN
    |   |-- dists
    |   `-- pool
    `-- source
        |-- dists
        `-- pool

Keeping the same layout as today below dists and pool might be
aesthetically unpleasing, but it makes the transition surely easier,
and it allows to re-create a combined pool easily. This can be
important to avoid changes in the sources.list for many deployed
systems. (That is, ftp.debian.org would be created from a selection
of architectures of ports.debian.org, but with the same layout as

> > The increased number of source packages could be alleviated by purging
> > binary packages automatically (with an advance warning) from testing if
> > the "best effort" turns out to be not timely enough. I'm thinking of
> > something like:
> >   - Source wasn't referenced for 2 weeks by any release candidate
> >     distribution -> warning
> >   - After 4 weeks -> removal of the corresponding binaries
> > This means weeding out obsolete source packages needs at least a
> > 4 week freeze, which seems to be the minimum anyways.
> > If an SCC testing repository gets badly out of shape (== lots of
> > uninstallable packages), dropping it means simply stopping the testing
> > migration and/or clearing the Packages.gz, depending on the future
> > prospects to get the work done.
> If a port is going to try to keep up with the release, then I think it
> should go all the way; if we're going to constrain the new versions of the
> package that are allowed into testing based on what the core RC archs are
> doing, then I think you also have to consider just kicking the arch out of
> testing completely when it starts lagging behind this badly.  Is a port that
> lags 4 weeks behind a package on any kind of regular basis actually going to
> be useful once it's tagged "stable"?  4 weeks is barely as long as we're
> allowing for the sarge freeze, and *every* upload during that period is
> likely to be an RC bugfix that architectures would want to keep up with.

If such a problem occurs regularily, then we need some better way to
restrict the port to a subset of packages than what's currently done
via P-a-s, true. Daniel Jacobowitz' idea of "subtesting" looks like
a solution.


Attachment: signature.asc
Description: Digital signature

Reply to: