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
signature.asc
Description: Digital signature