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

Re: Renesas SH4 support in emdebian

On Wed, 27 Jan 2010 16:01:41 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:

> Neil Williams <codehelp@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.

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.

Grip uses three repositories:

filter/ - a selective mirror of a standard Debian mirror with one pool.
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.


Neil Williams

Attachment: pgpyjo8_zheqa.pgp
Description: PGP signature

Reply to: