Neil Williams <codeh...@debian.org> writes: > On Wed, 27 Jan 2010 16:01:41 +0100 > Goswin von Brederlow <goswin-...@web.de> wrote: > >> Neil Williams <codeh...@debian.org> writes: >> >> > I can find some packages at: >> > http://ftp.ch.debian.org/debian-ports/ >> > >> > Unfortunately, that mirror uses what appears to be a non-standard >> > filesystem for the archive itself. Instead of pool/ containing >> > files of all architectures, it is split into pool-sh4/ and many >> > others. There are various areas where '/pool/' is assumed and >> > hard-coded in various scripts and programs that handle genuine >> > Debian package archives. (I'm not just talking about apt, this is >> > more about packages like reprepro which need to be able to retrieve >> > the packages themselves.) >> >> If they don't grog what the Packages file says then they are extremly >> buggy. I don't belive reprepro cares one bit where the deb is located >> upstream as it only needs to follow the Filename entry in Packages. > > You're misunderstanding the problem - you're thinking of it > downstream (apt), the problem exists upstream (repository creation). The > issue arises *before* the Packages file is created in the local > repository, i.e. when trying to automate the creation of a new archive > to use these port archives as a base for subsequent modification of the > packages and inclusion into another repository. It isn't a case of just > rsync because only a part of the archive is needed (one package at a > time). There is no easy way to reconstruct the archive to what it would > be on ftp.debian.org if the sh4 arch was to be accepted as a release > architecture for Debian main.
Sure there is: reprepro. :) > When there is only one pool/ directory (a standard Debian mirror ala > ftp.debian.org), a single update rule can handle all architectures and > all components for one suite. > > When there is more than one pool*/ directory, there has to be a manual > step to work out how to create one pool from the many. In this case it > means multiple update rules per suite. Not really, fetch Packages file, iterate over all packages therein, convert and dump them into the local archive. As said, a tool that doesn't use the Packages file to get the url for debs but just assume files are in certain places is just buggy. > Grip uses three repositories: > > filter/ - a selective mirror of a standard Debian mirror with one pool. Which only has one pool if you use reprepro to fetch the packages. So there is no problem there even with the grip scripts assuming a fixed pool/main/<hash>/<package/ path. > grip/ - the processed package repository, again in standard format > locale/ - the TDeb mirror, packages built during the grip processing. > > The problem with pool*/ vs pool/ affects the initial setup of the > filter repository - this stage can be automated *if* the mirror from > which we update is a typical Debian mirror with a single pool/. > reprepro can work with the pool*/ - it just needs manual tweaking of > the update rules in the first place. Don't see where: conf/distributions: Origin: sh4 Label: sh4 Suite: sid Codename: sid Version: 666 Architectures: sh4 Components: main Description: Debian sh4 Update: - sh4 SignWith: yes DscIndices: Sources Release . .gz DebIndices: Packages Release . .gz conf/updates: Name: sh4 Method: http://ftp.ch.debian.org/debian-ports results in: aptmethod got 'http://ftp.ch.debian.org/debian-ports/pool-sh4/main/3/3dchess/3dchess_0.8.1-16_sh4.deb' aptmethod got 'http://ftp.ch.debian.org/debian-ports/pool-sh4/main/4/4g8/4g8_1.0-3_sh4.deb' aptmethod got 'http://ftp.ch.debian.org/debian-ports/pool-sh4/main/6/6tunnel/6tunnel_0.11rc2-2_sh4.deb' pool/main/3/3dchess/3dchess_0.8.1-16_sh4.deb pool/main/4/4g8/4g8_1.0-3_sh4.deb pool/main/6/6tunnel/6tunnel_0.11rc2-2_sh4.deb You do filter by package name and not by pool/main/<hash>/<name>, right? MfG Goswin PS: sorry to be so adversarial but I think there just is no problem here. -- To UNSUBSCRIBE, email to debian-embedded-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
