Re: Ruby packaging in wheezy: gem2deb, new policy, etc.
> Agreed on this as well. As gems are added for more apps, libFOO-ruby
> doesn't make nearly as much sense as ruby-FOO.
I feel like libFOO-ruby makes more sense because ruby-FOO does not mention that
the package is even a library. The Python naming scheme feels like it is
deviating from the Debian naming scheme I've always known.
> 3) Should we change our packaging workflow? Using gem2deb, it would be quite
> easy to use git-buildpackage with:
Please think of people that do not have direct access to the internet.
Subversion is rough offline. Particularly 'svn log'.
> 4) How should we migrate to the new packages? If we want to enable test suites
> during build (which would be a good thing)
Testing is great but it depends on other packages|gems. I feel like Debian has
it's own QA that does not rely on mocha or another gem that catches upstream's
agile eyes.
I'd like to bring up the debate about 1.8 still being in Debian. We should drop
it in favor of having only one interpreter. Right now I have 3 ruby
interpreters on my machine: 1.8, 1.9.1, and trunk. I understand that there are
a lot of packages that rely on 1.8 but I bet they have newer releases that run
on 1.9.* or are dead upstream. Unlike python2* there will be no more ruby1.8.*
releases.
I'm not a Debian Developer, just a user, so these decisions are ultimately up
to everyone with the debian.org email addy but I will gladly conform any
packages I have in pkg-ruby-extras to whatever is decided.
Reply to: