Ticket #27 (closed: fixed)

Opened 5 years ago

Last modified 4 years ago

downloading source is too hard

Reported by: gdt Assigned to:
Keywords: Cc:

Description

I am maintaining gtkimageview in pkgsrc, and normally one specifies an unchanging MASTER_SITE, and a DISTNAME, and has a default suffix (.tar.gz). But the URL for each tarball changes with version. It would be really nice to put them in a directory on the web server where they can be fetched normally, without interacting with trac, and just link to that, instead of using trac attachments.

Change History

09/01/08 05:26:57 changed by bjourne

I'll look into that. Do you know that you can directly link to the tarballs using the raw links? For example: http://trac.bjourne.webfactional.com/attachment/wiki/WikiStart/gtkimageview-1.6.1.tar.gz?format=raw

09/01/08 14:01:15 changed by gdt

Yes, I realized that I could get the tarball with the ?format=raw, and noticed that when downloading it manually. The problem is that pkgsrc doesn't have support for that idiom; it expects a MASTER_SITE that is a list of things like "http://foo.example.com/bar/baz/" (but can be any ftp or http url that ends in /) and then a DISTNAME that looks like "foo-bar-M.N", together with an EXTRACT_SUFX that's typically .tar.gz. It then uses the DISTNAME to make the package name (and version), and the EXTRACT_SUFX to know which tool to use to unpack, and the DISTNAME to know what directory it is supposed to unpack into. Then the distfile (your tarball) is, absent restrictions present with non-free software, mirrored to MASTER_SITES_BACKUP, which contains URLS like ftp://ftp.NetBSD.org/pub/NetBSD/packages/distfiles/. So then the effective value of MASTER_SITES for someone trying to download/build would have the real site first, followed by the mirrors, and each would be combined with the DISTNAME and tried in turn. This has turned out to work really well, automatically working around temporarily unreachable sites, and preserving copies of free software when upstream sites suddenly disappear.

With the gtkimageview tarball URL you gave, it doesn't fetch a file that is the last component of the URL, and it doesn't end in a suffix that indicates how it is unpacked. When the file is placed in a backup fetch directory, then the URL has to be different in form, not just have a different MASTER_SITES prefix.

It would of course be a fair question to ask if this is really a pkgsrc bug for not supporting upstream packages distributed as trac attachments. Basically pkgsrc has grown support for common cases, and for what it's worth this is the first time I've run into it myself.

I've worked around this by downloading the distfile manually and putting it on my own server and setting MASTER_SITES to that, leaving your trac as the HOMEPAGE and with a commented-out MASTER_SITES pointing to that, along with a link to this ticket.

BTW, I'm using gtksourceview because of ufraw - I'm one of the ufraw developers (although not super active - mostly fixing portability issues).

01/04/09 18:01:40 changed by divanorama

Hi, I too don't like that suffix :)) Here http://trac.edgewall.org/attachment/wiki/TracWiki/mediawiki2trac.py I see a better formatted link http://trac.edgewall.org/raw-attachment/wiki/TracWiki/mediawiki2trac.py

Is it possible to configure such urls for gtkimageview? Currently it gives "No handler matched request to /raw-attachment/wiki/WikiStart/gtkimageview-1.6.3.tar.gz"

01/06/09 10:15:27 changed by divanorama

raw-attachment feature is available in 0.11 version of trac.

04/05/09 21:05:42 changed by bjourne

  • status changed from new to closed.
  • resolution set to fixed.

I can't upgrade the trac version on my hosting provider unfortunately. However all future release tarballs will be put here http://trac.bjourne.webfactional.com/chrome/common/releases/ which should solve the problem with the format=raw suffix.