[DRE-maint] Distributing versions of will_paginate in Linux distributions

[Gunnar Wolf]

Mislav Marohni?? dijo [Wed, May 21, 2008 at 02:02:43PM +0200]:
> Hey Gunnar,
> 
> Thanks for your work on this. While I like RubyGems, I also used Ruby extras
> packages in the past on Debian and Ubuntu servers because of ease of install
> and stability.

Perfect! :D

> The GitHub tarball is indeed dynamically generated, but it's size can be
> checked to see if it has changed---you don't have to rely on timestamp.

Let me illustrate:

0 gwolf at mosca[1]~$ cd /tmp/
0 gwolf at mosca[2]/tmp$ wget --quiet http://github.com/mislav/will_paginate/tarball/2.3.2 -O will_paginate.1.tar.gz
0 gwolf at mosca[3]/tmp$ wget --quiet http://github.com/mislav/will_paginate/tarball/2.3.2 -O will_paginate.2.tar.gz
0 gwolf at mosca[4]/tmp$ md5sum will_paginate.{1,2}.tar.gz
e8e0407a276e32f2c052902427f29ce0  will_paginate.1.tar.gz
950c1144889c709083c2df205dc897db  will_paginate.2.tar.gz

The tarball contents are identical (i.e. diff -ru shows no
differences), so I can only guess the difference is the tarball
creation timestamp. 

Why does this matter to us? Because part of the Debian packaging
involves the original .tar.gz - which is signed to have a determinate
MD5. What we are doing now (although it's really suboptimal) is to
take a tar.gz from your code and putting it in a static location [1],
but you will understand it does not really solve the situation.

> When you said "page with 2 links", what do you mean when you say the other
> link points to a "blessed" tarball? If that is some packaging terminology,
> you'll have to explain it to me.

Yes, I'm sorry, I used a poor choice of words - By "blessed", I ment
"official", "made by you". I am using this message to think out loud
(after all, it's also directed to the pkg-ruby-extras group, and they
might have something to say)... but I hope this will be clearer this time.

One of the tools we use (and I'm sure other distributions have similar
ones) is uscan, which periodically scans the developer's page and
reports to us (and downloads the tarball, of course) when a new
version is released. So, most of our packages have a uscan driving
file (debian/watch) like this:

    version=3
    http://rubyforge.org/frs/?group_id=81 .*/color-tools-(\d.*)\.tar\.gz

The first argument indicates the URL to download and scan, the second
argument is an expression that tells uscan what to look for and
download in the given page's links.

Playing around, I got to an ugly debian/watch that works:

    version=3
    opts=downloadurlmangle=s/commits/tarball/,filenamemangle=s/^.*commits.(.*)/libwill-paginate-ruby_$1.orig.tar.gz/ \
        http://github.com/mislav/will_paginate/tree/master /mislav/will_paginate/commits/([\d\.]+)

But, of course, each .tar.gz will be different. What would be great is
that, besides tagging each release, you put a static page with the
.tar.gz you produced itself.

I am sending a second mail with a patch for your Rakefile; if you
apply it and run 'rake package', it will generate the Gem and tar.gz
files in pkg/.

Greetings,

[1] http://pkg-ruby-extras.alioth.debian.org/upstream-cache/libwill-paginate-ruby/

-- 
Gunnar Wolf - gwolf at gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF