[arch-general] Ruby gem packages in Arch

[Maxime Gauduin]

On Mon, Jan 13, 2014 at 11:52 AM, Paul Gideon Dann <pdgiddie at gmail.com>wrote:

> On Monday 13 Jan 2014 11:38:57 Alfredo Palhares wrote:
> > I agree with you, some ruby-packages just are a royal pain in the arse to
> > maintain. Sometimes i wish I just when with rbenv[1] and call it a day. I
> > still have some packages that use the old naming convention.
> >
> > But like you said the worst scenerio is to deal with multiple versions,
> like
> > one fact you need to update an gem, but packages that depend on it need
> an
> > older version of it, so now you have to have 2 versions of that gem.
> >
> > It can be done, we just need more man power to put quality packages.
>
> Forgive me: I'm a little unclear on why it's better to have the packages
> available via
> pacman?  I do development in Rails and am personally perfectly happy to use
> rubygems (and rbenv, for larger projects) for gem management.  I suppose
> it does
> mean there are files installed on the system that pacman can't identify,
> but personally I
> use rubygems enough that I have no problem handling the concept of two
> package
> managers that operate in different domains...
>
> I'm not trying to dismiss your effort, I'm just concerned that this seems
> a little like
> duplication.
>
> Paul
>

IMHO, the reason why you would choose to use rubygem over pacman depends of
how extensive a ruby user you are. I like to have gems handled by pacman,
but I only use a few of them and don't need to have several versions of the
same gem. Having them installed system-wise also makes them easily
available to all users. That being said, you can achieve the same with
rubygem by sharing a common ruby home between your users. As for the files
not handled by pacman, home dirs are not referenced anyway so having gems
in it really doesn't hurt.

Regarding naming convention, ultimately, I believe the decision is up to
the maintainer, not to some script. I have a few ruby packages in
[community], some of them containing executables in /usr/bin. I still chose
to keep the ruby prefix for 2 of them (namely ruby-term-ansicolor and
ruby-treetop) because as Anatol pointed out, they are also libs. I did not
for rubyripper and taskjuggler3 though, and I won't change that.
ruby-rubyripper would just be silly, and taskjuggler3 is a fairly big piece
of software, and it's pretty obvious it's written in ruby, there is no need
for a prefix. You can find the rubygem prefix on some other distros, but I
don't really see the point.

Now, about versioning: Arch is all about bleeding edge, keeping previous
versions in our repo is against our policy. There are only a few special
cases and we avoid to do that unless half the world still lives on the
previous version. Keeping only the latest not only greatly simplifies our
packaging life, but it also encourages devs to always keep their code up to
date with the latest and greatest. Sure, ruby deps may be more flexible,
but there's no harm in having the latest release, even if it works with an
older one.

Ultimately, I'd say rubygem is best for extensive ruby user, unless you
have a lot of time and really want to have pacman handle them. Still if you
need more than 2 versions of the same gem, rubygem is the way to go.

Cheers,
-- 
Maxime