Re: apt and publicfile's httpd

On Mon, 25 Oct 2004 [email protected] wrote:

> rpm	http://djbware.csi.hu apt djbware
> rpm-src	http://djbware.csi.hu apt djbware

Sorry, but I wasn't able to reproduce your problem. I am, however, using
the unmodified Debian version of apt, which may behave differently (my
apt doesn't understand 'rpm' lines nor the directory structure you
showed).

I did run a brief test in which I used apt-get to grab a Sources list
and successfully run a command similar to the one you gave below (though
I obviously used a .deb and a different directory structure). The http
server was publicfile, and everything worked fine.

> # apt-get source qmail
> Reading Package Lists... Done
> Building Dependency Tree... Done
> E: Unable to find a source package for qmail

Odd that it doesn't complain about an error in the http connection. Are
you sure you ran 'apt-get update' after changing your sources file and
before running this command? It might simply not know where to look.

Another possibility: some of your files are .bz2 and .rpm files.
publicfile doesn't understand either of these extensions, and will
claim a content-type of text/plain. apt may behave oddly as a result.
Try renaming the file according to the convention here:
   http://cr.yp.to/publicfile/filetypes.html
Since you may not have the luxury of choosing the filenames that apt
looks for, you'll probably want to either modify the source (see
filetype.c), use Uwe Ohse's patch to put file types in environment
variables:
   http://www.ohse.de/uwe/patches/publicfile-0.52-filetype-diff
or use my patch to avoid ugly filenames:
   http://peff.net/patches/publicfile-0.52-filetype-links-diff

If that doesn't work, then the next step is probably to look at the http
logs and connection. Check the httpd logs to see what file is being
requested. If the file is found, then try strace-ing apt to see what the
http conversation looks like. If nothing looks obvious, try posting a
transcript of the http headers.

-Peff