On Mon, Jan 13, 2014 at 11:52 AM, Paul Gideon Dann <pdgiddie@xxxxxxxxx>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
