[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: uscan, watchfiles and multiple tarballs



[ fully quoting your post to the benefit of the freshly Cc-ed bug log ]

On Sun, Nov 15, 2009 at 06:27:13PM +0100, Julien Cristau wrote:
> with v3 source packages being accepted into the archive I started
> looking at how I could split up the x11-apps and friends tarballs by
> shipping the tarballs from upstream directly, and I'm trying to get
> uscan to download them for me.
> 
> Basically I have tarballs for bitmap, oclock and friends at
> http://xorg.freedesktop.org/releases/individual/app/ each with its
> version number, and I'd like to get, say,
> x11-apps_7.5+1.orig-{bitmap,oclock,...}.tar.bz2
> 
> This would mean that there's no direct mapping from the debian package
> version (in debian/changelog) from/to each upstream tarball version (in
> foo/configure), and I can't seem to make that work with uscan (I can
> make it download the tarballs[1], just not rename them as I'd like).  I'd
> welcome any suggestions (explaining why I'm insane works, too)…

Hi, I hit a similar issue when packaging some Python libraries [1], the
result was filing 531321. With Adam we intended to work on it at last
DebConf, but eventually we were too busy working on other stuff to
actually do that.

My idea back then was actually simpler than yours: simply allow multiple
declarations in debian/watch and kind of use a "always force" mode where
uscan always download everything. Around that you can have some
repacking logics and a dumb diff that checks whether the freshly
repacked tarballs differs from the old one.
What you propose/hint is clearly better.

The main design point to decide upon is where to store the information
about the last downloaded version of each sub-tarball. debian/changelog
does not look like a good idea to me, because the amount of information
can get messy.

How about deciding that the debian/watch* "namespace" is reserved to
uscan? At that point we can imagine a debian/watch.something file which
keeps track of sub-tarball versions and make uscan automatically update
it when downloading new sub-tarballs and/or by a specific invocation.

Any other ideas about where to make uscan store such information?

Cheers.

[1] basically, when you have several related .egg files each of which
    just a few Kb, in such cases having one package per-egg is really
    overkilling

-- 
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..|  .  |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime

Attachment: signature.asc
Description: Digital signature


Reply to: