Request 270 was acted upon. _________________________________________________________________________
URL: https://rt.openpkg.org/id/270
Ticket: [OpenPKG #270]
Subject: [apt] indexes broken
Requestors: [EMAIL PROTECTED]
Queue: openpkg
Owner: Nobody
Status: new
Transaction: Ticket created by [EMAIL PROTECTED]
Time: Sun Sep 21 17:45:52 2003
_________________________________________________________________________
It seems that there are some fairly substantial differences between the
filenaming conventions of the indexing tools ("genbasedir") and the
client-side tools ("apt-get").
With "genbasedir", when one attempts to index a set of distribution
components (say, "foo" and "bar") the script fails because in some
places it expects to find a directory titled 'foo' and in other places
it expects to find a directory called 'RPMS.foo'. Prior to OpenPKG path
adjustments, all files were expected to be found in 'RPMS.foo'.
This problem can be worked around by making symlinks, but there are
deeper problems with the locations in which resulting "release" files
are placed. Formerly (before OpenPKG patches to adjust paths) these used
to go in a subdirectory called "base", which is what apt-get expected.
Now the release files seem to go in each "RPMS.XXX" directory, but
apt-get doesn't (yet?) know about this. It issues HTTP requests to
download non-existent release files from the root path of the
repository.
Some information about my testing environment: I have a repository set
up with two distribution components: 'openpkg-current' (packages from
your official FTP site) and 'cis' (our on-site custom packages). I use
the "--flat" option to genbasedir. So the usage looked like:
genbasedir \
--bz2only \
--progress \
--flat \
${TOPDIR} \
'cis' 'openpkg-current'
The directory structure looks like this:
${TOPDIR}/
RPMS.cis/
*.rpm
RPMS.openpkg-current/
*.rpm
base/
Perhaps the usage expectations have changed with the patches, and I'm
just mishandling the genbasedir tool now?
signature.asc
Description: PGP signature
