Dear Colleagues,
On Mon, 2008-09-01 at 12:21 -0400, Mathias Gug wrote: > Hi, > > I'd like to appeal against motu-release decision to revert the > libgem-ruby upload 1.3.0~RC1really1.2.0-2ubuntu2 based on the following > reasons: > > On Fri, Aug 29, 2008 at 11:39:52PM +0200, Stefan Potyra wrote: > > > > first off, this was not an easy decision. It didn't happen so far yet, that > > motu-release had to decide if an upload should indeed get reverted, and > > hence > > this decision was done only with consent among all motu-release members. > > The > > key factor in regards to this decision was if this upload does work towards > > making an improvement in regards to the intrepid-release, or if it did in > > fact > > result in the opposite, hence making it unfit for release. > > > > Let me reiterate what the upload was trying to achieve. As outlined in > [1]: > > Providing binaries shipped by gems on the default path. > > In hardy, the end user using a gem (let's say the rails gem) would > have to do the following things: > > 1. sudo apt-get install rubygems > 2. sudo gem install rails > 3. Modify the default PATH in the environment to include > /var/lib/gems/1.X/bin/ so that the rails command can be invoked from the > command line. > > The upload aims at removing step number 3 from the process by symlinking > the gem binary from /var/lib/gems/1.X/bin/ into /usr/local/bin/. > > [1]: https://lists.ubuntu.com/archives/ubuntu-devel/2008-August/026240.html Step 3 is the right thing to do, IMHO. The Sysadmin who "needs" to use gem in the first place, is doomed anyhow. But letting the sysadmin do his work, he/she knows very well what to do with bins/libs installed by gem under /var/lib/gems/* . We shouldn't overrule him/her. A manual link is just a finger click away. But it's the sysadmin who is doing this. Furthermore, I tried to get the old source package of the gem I was giving as example. Sadly it's gone. Anyways, to make it again clear what happend with this gem was this: Gem has the possibility to give e.g. DESTDIR or other installation locations to all included dependencies. The same as in RPM spec files or debian/rules files. No question, this is a good way, if that works as explained, everything is fine. But now, the package of this particular gem wasn't a pro, and had no clue about attaching the needed shell vars to his makefile, so he just overruled the sysadmin or the guy who was in favour to compile this gem, and the gem packager just forced: /usr/* as installation path. As there is no real trusted source of gems, mostly all packages are non-signed, it's quite difficult for the "normal rails user" to know what happens on his/her system, especially when building those software, which is mostly necessary, because of different other deps e.g. libmysqlclient, or whatever. The problem is not distro-specific, it's upstream cruft, because they don't have a good policy for packaging those gems. If there is something like the debian policy, or the redhat rpm policy, I wouldn't object, but as long there is nothing like that, most sysadmins need to be careful, and in most cases they are, especially when they fall into a pit with gem. Even if I'm sounding like an old fart, regarding this, but I think the old way of installation of gem parts in /var/lib/gems/* is much better, and letting the sysadmin do the work is even more sane. The other fact is, that most gems are using newer software deps then older distros (e.g. dapper, hardy, etch, lenny (TBR)) have. So it's quite usual, that the sysadmin needs to break his distro anyways with new lib dependencies. That's why we shouldn't encourage the use of gems anyways. Much better would be, if we would have a policy in place, as we have with php pear stuff or with perl modules. the more packaged gems we have in our archives the better (this is not ubuntu or debian specific). So no sysadmin has to break his system because of a faulty webapp. regards, \sh -- Stephan '\sh' Hermann | OSS Developer & Systemadministrator JID: [EMAIL PROTECTED] | http://www.sourcecode.de/ GPG ID: 0xC098EFA8 | http://leonov.tv/ 3D8B 5138 0852 DA7A B83F DCCB C189 E733 C098 EFA8 -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
