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

[Mislav Marohnić]

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.

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.

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.

- Mislav


On Wed, May 21, 2008 at 1:44 AM, Gunnar Wolf <gwolf at gwolf.org> wrote:

> Hi,
>
> I have just prepared a package for will_paginate [1] for its inclusion in
> Debian, and in a couple of days it will become installable via apt-get
> for users of our unstable branch (and will, of course, in due time
> arrive to the official release). I am uploading it as part of the
> Debian pkg-ruby-extras team [2], a team that collaboratively maintains
> currently 86 Ruby modules.
>
> We strive to make Debian-using Ruby programmers' lifes simpler by
> providing pakcages for the most popular modules. As you know, Ruby
> Gems are the most popular way of distributing Ruby - But it is not
> really compatible with large-scale installations requiring stable (and
> long-supported) versions of the software.
>
> Where am I trying to get to? Basically, your module has been a
> pleasure to package. It took me only some hours - Even though I am
> still learning my way around Git. I packaged tag 2.3.2 (of course, as
> version 2.3.2). However, in order to do this, I did a 'git checkout
> 2.3.2', then removed the Git directory, and prepared a tar.gz with the
> contents. I found out too late I could have requested GitHub to
> prepare a tar.gz for 2.3.2 [3]... But I fear this is auto-generated on
> request (i.e. I requested for the file twice, and although the
> contents are the same, the files themselves are different - timestamps
> do not match, I guess)
>
> It is very important for us, QA-wise, to be able to have an official
> original .tar.gz to refer to, the "pristine sources", guaranteeing the
> users we deviate as least as possible from the authors, and helping us
> target a specific release. Also, as we track several dozens of
> modules, we use some tools to track each of the packages [4].
>
> If you were able to provide a page, even a static ugly one, with links
> to a statically generated and blessed .tar.gz, you would make our work
> significatively easier. Please consider doing so.
>
> Just as two final links (which we have to update, a couple of points
> are somewhat updated. Specifically, we have worked around our request
> of "use setup.rb" - I did use setup.rb on your module, and it worked
> beautifully :) ), please take a look at our position on RubyGems [5]
> and our request to upstream developers [6].
>
> Thank you very much,
>
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=482073
>
> [2] http://pkg-ruby-extras.alioth.debian.org/
>
> [3] http://github.com/mislav/will_paginate/tarball/2.3.2
>
> [4] http://pkg-ruby-extras.alioth.debian.org/cgi-bin/qareport.cgi
>
> [5] http://pkg-ruby-extras.alioth.debian.org/rubygems.html
>
> [6] http://pkg-ruby-extras.alioth.debian.org/upstream-devs.html
> --
> Gunnar Wolf - gwolf at iiec.unam.mx - (+52-55)5623-0154 / 1451-2244
> PGP key 1024D/8BB527AF 2001-10-23
> Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIM2JO2A7zWou1J68RAthPAJ4vVGECXNmvEaVISWZjuJJGCzYL9gCgxhKC
> 1KBLXH30kjCBRwkqcY/v8lA=
> =EPsv
> -----END PGP SIGNATURE-----
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/attachments/20080521/f7e4c3af/attachment.htm