Skip to content
This repository

A view with all tarballs as links #96

Closed
nomeata opened this Issue · 9 comments

4 participants

Joachim Breitner Matthew Gruen Duncan Coutts Edsko de Vries
Joachim Breitner

For Debian, we need a way to specify a so-called “watch file” for each package, which contains instructions on how to obtain the list of available versions and their tarballs. Previously, this file looked like

opts="downloadurlmangle=s|archive/([\w\d_-]+)/([\d\.]+)/|archive/$1/$2/$1-$2.tar.gz|,\
filenamemangle=s|(.*)/$|hakyll-$1.tar.gz|" \
    http://hackage.haskell.org/packages/archive/hakyll \
    ([\d\.]*\d)/

but this broke with hackage2 (The archive URL has gone).

Reading this information from, say, http://hackage.haskell.org/package/hakyll, is difficult, for example the current version is not a link there.

Therefore I’d like to suggest a new view, e.g.,
http://hackage.haskell.org/package/hakyll/tarballs
which contains a classical listing of all tarballs of available versions, as links. This would greatly simplify our watch file to something like

http://hackage.haskell.org/package/hakyll/tarballs .*\.tar\.gz
Matthew Gruen
Collaborator

This should be reasonably easy to implement (just scan over the [PkgInfo] for tarballs, for a given package). Definitely sounds necessary. The ideal solution seems to be an Apache directory listing, which we don't have anymore :)

The main question is about maintaining this long-term. @dcoutts: Is /package/:package/tarballs the best place for this to go? Should it go into the Core feature, or a more distro-specific one?

Matthew Gruen
Collaborator

As nomeata commented on IRC, it seems like the new URL scheme might also break Fedora. (see HACKAGE-DEFAULT, although I'm unclear about what the regex alias is): https://fedoraproject.org/wiki/Upstream_release_monitoring

Duncan Coutts
Owner

Can you be a bit more specific about what Debian needs? There is already a standard url scheme for the tarballs, so is all you need a way to get a list of versions, or do those really have to be html links to tarballs?

If we can do something that makes sense generally then we can do that, otherwise we can just make something specific for debian. I'm not sure that the /package/:package/tarballs suggestion does make sense generally.

For Fedora it looks like we could make it work with a /package/:package/versions resource that contains a list of all the versions for that package name (as plain text, json, or html links). Hopefully that'd work for debian too.

Joachim Breitner

Unfortunately, the tool Debian uses (uscan) is not very flexible; it assumes that there is one page, which contains links (which are recognizable by a regex, which is error-prone on the package overview page due to the description), one per version. Ideally the link goes directly to the tarball, but some mangling of the link’s href to fix that is possible (this was done using the current scheme). But then it hard-codes even more of the page layout and can break (as it has done now).

A /package/:package/tarballs view might not be super useful in general, you never know what people might use it for, and the implementation and maintenance burden would be low, so this would still be my preferred option.

If you really would like to leave this out of hackage I can probably hack up a tool that creates such pages somewhere else, and use that.

Edsko de Vries
Collaborator

We already have a Distros feature, might be reasonable place to support distribution-specific views?

Joachim Breitner nomeata referenced this issue from a commit in nomeata/hackage-server
Joachim Breitner nomeata Create a /packages/:pkgname/tarballs view
A simple view containing all tarballs of a package. Fixes: #96.
4c399ba
Joachim Breitner nomeata referenced this issue from a commit in nomeata/hackage-server
Joachim Breitner nomeata Create a /packages/:package/tarballs view
A simple view containing all tarballs of a package. Fixes: #96.
d4ecc36
Joachim Breitner

I created a pull request, hoping that the discussion will stay shorter than the code diff, and to have something concrete to talk about.

Matthew Gruen
Collaborator

Btw, one reason why this might go into a distro feature, but probably not the Distro feature, is because that feature is all about stable versions of packages in distros, whereas this is about upstream maintenance (much earlier in the pipeline, such that they are orthogonal from Hackage's point of view).

Duncan Coutts
Owner

Ok, #108 was merged.

Joachim Breitner

Just so that I can plan: When do you expect the change to hit the deployed hackage?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.