Package: ftp.debian.org
Currently dgit runs ssh coccia dak ls, which is clearly mad, and pokes
around in coccia's copy of the archive with readlink (to canonicalise
suite names). I would the archive to have better support for a couple
of these operations, specifically
- what version of X is in suite Y ?
- what is the path to that .dsc in mirrors ?
- what is the stable name of suite Y ? (eg for "stable" it
should return "wheezy").
These operations should be available to anonymous users and ideally
there would be some cryptographic integrity protection too.
See
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720170
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720171
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=720176
Joerg and I have been having a conversation about this; he said I
should file a bug. Here is my reply to Joerg's most recent mail:
Joerg Jaspert writes ("Re: Comments regarding dgit_0.1_i386.changes"):
> On 13308 March 1977, Ian Jackson wrote:
> > - what is the path to that .dsc in mirrors ?
>
> Right, that needs some sql.
I would be happy to talk directly to the dak database, or implement
new code for dak. Should I just clone dak and start hacking and send
patches ? Which of the git repos at
https://ftp-master.debian.org/git/
should I start with ?
> > - what is the stable name of suite Y ? (eg for "stable" it
> > should return "wheezy").
>
> dak admin s show stable|grep '^Codename'
That sounds plausible, although there is still this problem:
"dak admin s show sid", for example, fails. I assume that if I write
my own sql, eg as new dak commands, this is easily fixed.
> > These operations should be available to anonymous users and ideally
> > there would be some cryptographic integrity protection too.
>
> That one currently kicks it.
>
> The last req one would be easy to put onto the mirrors in a file, it
> doesn't change so often. And may make sense elsewhere too. Right now one
> CAN parse the README file, the format is strictly the same since
> beginning, but thats meh.
Right.
> The middle one [what is the path to the .dsc of package X version V
> in suite Y]: Could you check indices/package-file-map.bz2 on your
> mirror, can you work with that?
The difficulty there is that it involves downloading an index of all
packages, when the user is probably only interested in one particular
package. That file is 4.5Mby, which for many source packages would
dominate the required downloads.
> The first [what version of X is in suite Y] currently simply has
> *no* way for anonymous.
Would it be acceptable for some machine somewhere to run a cgi/http
service (or another kind of daemon) to provide this information ? At
the moment there is a madison server on one of the qa machines but it
can return wrong information.
Eg, could I run a suitable CGI on coccia (which AIUI is a mirror of
ftpmaster with access to the same database) ?
I'm an experienced author of security software and of CGI programs,
and the program would probably be quite simple.
> > I would like to request that the archive have better support for a
> > couple of these operations, specifically
> > - what version of X is in suite Y ?
>
> Thats easy: dak ls
I have found another problem with this, which is the problem of
time/version skew. I don't know exactly how the archive and mirror
update process works, but I have observed that (a) it is possible for
multiple source versions of a package to show up in dak ls for a
particular suite (b) the latest version listed isn't necessarily
available anywhere yet. Is that right ?
What I do at the moment is take all the answers and try all of them in
order (on the selected mirror) by http until I find one whose .dsc
isn't 404. This doesn't feel right.
Suggestions and comments welcome.
> DM acls are exported since day 1 :)
Excellent, and thanks for the info in your other mail. For DM push
access I just need to find a way to provide the appropriate permission
on alioth. (This is therefore no longer relevant to this bug report.)
Thanks,
Ian.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
