Steve Langasek wrote:
[snip]
> > 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
was.
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
ports.debian.org
`-- 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
today.)
[snip]
> > 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.
Thiemo
Attachment:
signature.asc
Description: Digital signature