Debian Bug report logs - #448639
rubygems: please install gems in /usr/local/lib/gems/1.8

version graph

Package: libgems-ruby; Maintainer for libgems-ruby is Daigo Moriwaki <daigo@debian.org>;

Reported by: Lucas Nussbaum <lucas@lucas-nussbaum.net>

Date: Tue, 30 Oct 2007 17:45:03 UTC

Severity: minor

Fixed in version rubygems/1.7.2-1

Done: Daigo Moriwaki <daigo@debian.org>

Bug is archived. No further changes may be made.

Toggle useless messages

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
New Bug report received and forwarded. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #5 received at submit@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: submit@bugs.debian.org
Subject: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Tue, 30 Oct 2007 18:38:06 +0100
Package: rubygems
Version: 0.9.4-4
Severity: minor

Hi,

I thought a lot about the gem issues. I think that we should do the
following:

install gems in /usr/local/lib/ruby/gems/1.8 (instead of
/var/lib/gems/1.8), and put binaries in /usr/local/bin (instead of
/usr/bin).

provide an option to install gems in /usr/lib/ruby/gems/1.8. This could
be used by gem packaged as debian packages. (their binaries would then
go to /usr/bin)

What was the reason to install gems to /var/lib/gems in the first place?

Thank you,
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Daigo Moriwaki <daigo@debian.org>:
Extra info received and forwarded to list. Full text and rfc822 format available.

Message #10 received at 448639@bugs.debian.org (full text, mbox):

From: Daigo Moriwaki <daigo@debian.org>
To: Lucas Nussbaum <lucas@lucas-nussbaum.net>, 448639@bugs.debian.org
Subject: Re: Bug#448639: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Sat, 03 Nov 2007 14:07:41 +0900
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

severity 448639 wishlist
tags 448639 + wontfix
thanks

Hi Lucas,

Lucas Nussbaum wrote:
> I thought a lot about the gem issues. I think that we should do the
> following:
> 
> install gems in /usr/local/lib/ruby/gems/1.8 (instead of
> /var/lib/gems/1.8), and put binaries in /usr/local/bin (instead of
> /usr/bin).
> 
> provide an option to install gems in /usr/lib/ruby/gems/1.8. This could
> be used by gem packaged as debian packages. (their binaries would then
> go to /usr/bin)
> 
> What was the reason to install gems to /var/lib/gems in the first place?

/usr/lib is a preserved directory for Debian system where only official Debian
packages that are maintained by Debian developers are expected to put and update
their files. That's my understanding. Since gems that are installed by the gem
command are not Debian's, they should not go to /usr/lib.

Moreover, some gems may be packaged as Debian package (.deb) by Debian
developers. For example, you can get rake by both apt-get and gem. If gems are
installed to /usr/lib, files of which may conflict with ones of Debian packages.

/usr/local is a preserved directory for Debian user. I think that Debian
packages should not install any files there. Since the gem command from the
rubygems package belongs to Debian package, it installs nothing in /usr/local.

That's why I've selected /var/lib.



Thanks,
Daigo

- --
Daigo Moriwaki
daigo at debian dot org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHLAIdNcPj+ukc0lARAgy5AKDc/mOy9xwZXzZXtuPzxdPdnDjfsgCcCekJ
2TWUGIhkmmqaLHKxNPBWfmk=
=mCck
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #15 received at 448639@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Daigo Moriwaki <daigo@debian.org>
Cc: 448639@bugs.debian.org
Subject: Re: Bug#448639: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Sun, 4 Nov 2007 14:15:47 +0100
On 03/11/07 at 14:07 +0900, Daigo Moriwaki wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> severity 448639 wishlist
> tags 448639 + wontfix
> thanks
> 
> Hi Lucas,
> 
> Lucas Nussbaum wrote:
> > I thought a lot about the gem issues. I think that we should do the
> > following:
> > 
> > install gems in /usr/local/lib/ruby/gems/1.8 (instead of
> > /var/lib/gems/1.8), and put binaries in /usr/local/bin (instead of
> > /usr/bin).
> > 
> > provide an option to install gems in /usr/lib/ruby/gems/1.8. This could
> > be used by gem packaged as debian packages. (their binaries would then
> > go to /usr/bin)
> > 
> > What was the reason to install gems to /var/lib/gems in the first place?
> 
> /usr/lib is a preserved directory for Debian system where only official Debian
> packages that are maintained by Debian developers are expected to put and update
> their files. That's my understanding. Since gems that are installed by the gem
> command are not Debian's, they should not go to /usr/lib.
> 
> Moreover, some gems may be packaged as Debian package (.deb) by Debian
> developers. For example, you can get rake by both apt-get and gem. If gems are
> installed to /usr/lib, files of which may conflict with ones of Debian packages.
> 
> /usr/local is a preserved directory for Debian user. I think that Debian
> packages should not install any files there. Since the gem command from the
> rubygems package belongs to Debian package, it installs nothing in /usr/local.
> 
> That's why I've selected /var/lib.

Ok, thank you for the detailed explanation!

Some more related questions:
- couldn't it be possible to modify rubygems so that it installs
  binaries to (say) /var/lib/gems/bin ? this way, only this dir would
  have to be added to $PATH by users. Since a tarball installation of
  rubygems installs binaries to /usr/bin, it might just be a matter of
  changing a path somewhere...

- is it possible, using the rubygems package, to install a gem to
  /usr/lib/ruby/gems/1.8 ? This would be useful to create debian
  packages from gems.

Thank you,
-- 
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Gunnar Wolf <gwolf@gwolf.org>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #20 received at 448639@bugs.debian.org (full text, mbox):

From: Gunnar Wolf <gwolf@gwolf.org>
To: Daigo Moriwaki <daigo@debian.org>, 448639@bugs.debian.org
Cc: Lucas Nussbaum <lucas@lucas-nussbaum.net>
Subject: Re: [DRE-maint] Bug#448639: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Tue, 6 Nov 2007 18:13:08 -0600
Daigo Moriwaki dijo [Sat, Nov 03, 2007 at 02:07:41PM +0900]:
> /usr/lib is a preserved directory for Debian system where only official Debian
> packages that are maintained by Debian developers are expected to put and update
> their files. That's my understanding. Since gems that are installed by the gem
> command are not Debian's, they should not go to /usr/lib.

Completely agree here; /usr/lib is 0wn3d by dpkg.

> Moreover, some gems may be packaged as Debian package (.deb) by Debian
> developers. For example, you can get rake by both apt-get and gem. If gems are
> installed to /usr/lib, files of which may conflict with ones of Debian packages.

Gems which are packaged in .deb format stop being gems and become
handled just as Ruby... modules? Just like all of the packages we are
currently handling, so they should be in /usr/lib.

> /usr/local is a preserved directory for Debian user. I think that Debian
> packages should not install any files there. Since the gem command from the
> rubygems package belongs to Debian package, it installs nothing in /usr/local.

Umh... I don't like your logic - If we stuck to it, we would end up
with not being able to touch /usr/local with tar, cp or cat because
they are provided by Debian packages ;-) 

/usr/local is the area where the local system administrator should
unroll his mess. By using non-packaged Gems, the user is accepting
full responsability for this - he is installing a second package
management system inside his clean Debian system. So, the mess should
be unrolled inside /usr/local.

> That's why I've selected /var/lib.

In any case, /var is meant for variable data - things which are prone
to change by themselves (such as all kinds of databases). 

Of course, /var is to some extent a dumping ground for everything
which does not fit somewhere else, but... I still do not feel very
warm with this ;-)

Greetings,

-- 
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to "Shot (Piotr Szotkowski)" <shot@hot.pl>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #25 received at 448639@bugs.debian.org (full text, mbox):

From: "Shot (Piotr Szotkowski)" <shot@hot.pl>
To: 448639@bugs.debian.org
Subject: Re: [DRE-maint] Bug#448639: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Wed, 19 Dec 2007 14:44:39 +0100
[Message part 1 (text/plain, inline)]
Gunnar Wolf:

> /usr/local is the area where the local
> system administrator should unroll his mess.

Isn’t /opt for this? I never fully grasped the
official FHS difference between /usr/local and /opt…

> In any case, /var is meant for variable data - things which are
> prone to change by themselves (such as all kinds of databases). 

IIRC, the original reason for moving non-packaged gems out of /usr/lib
was that /usr should be mountable read-only (e.g., over a network), and
some gems tend to write into their own install directory.

-- Shot
-- 
> The reality is that maildir is only useful on some setups
> with remote mounted mailboxes and broken NFS locking.
Is there any other kind?   -- Marco d'Itri and Branden Robinson, debian-policy
[Message part 2 (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Gunnar Wolf <gwolf@gwolf.org>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #30 received at 448639@bugs.debian.org (full text, mbox):

From: Gunnar Wolf <gwolf@gwolf.org>
To: "Shot (Piotr Szotkowski)" <shot@hot.pl>, 448639@bugs.debian.org
Subject: Re: [DRE-maint] Bug#448639: Bug#448639: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Wed, 19 Dec 2007 12:56:05 -0600
Shot (Piotr Szotkowski) dijo [Wed, Dec 19, 2007 at 02:44:39PM +0100]:
> > /usr/local is the area where the local
> > system administrator should unroll his mess.
> 
> Isn???t /opt for this? I never fully grasped the
> official FHS difference between /usr/local and /opt???

Umh... /usr/local is more traditional ;-) 

/usr/local/bin is in your default $PATH, /usr/local/lib in your
ldconfig... It just feels more natural. 

/opt is usually just a disorganized junkyard ;-) while /usr/local
looks like Unix.

> > In any case, /var is meant for variable data - things which are
> > prone to change by themselves (such as all kinds of databases). 
> 
> IIRC, the original reason for moving non-packaged gems out of /usr/lib
> was that /usr should be mountable read-only (e.g., over a network), and
> some gems tend to write into their own install directory.

Umh... If a gem requires writing something in its install directory
once it is installed, something is fundamentally wrong. BTW, remember
that gems (which are, after all, just libraries) are meant to be used
systemwide, be it by administrators or by regular system users!

-- 
Gunnar Wolf - gwolf@gwolf.org - (+52-55)5623-0154 / 1451-2244
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973  F800 D80E F35A 8BB5 27AF




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Vincent Fourmond <fourmond@debian.org>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #35 received at 448639@bugs.debian.org (full text, mbox):

From: Vincent Fourmond <fourmond@debian.org>
To: Gunnar Wolf <gwolf@gwolf.org>, 448639@bugs.debian.org
Cc: "Shot (Piotr Szotkowski)" <shot@hot.pl>
Subject: Re: rubygems: please install gems in /usr/local/lib/gems/1.8
Date: Wed, 19 Dec 2007 20:30:16 +0100
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Gunnar Wolf wrote:
> Shot (Piotr Szotkowski) dijo [Wed, Dec 19, 2007 at 02:44:39PM +0100]:
>>> /usr/local is the area where the local
>>> system administrator should unroll his mess.
>> Isn???t /opt for this? I never fully grasped the
>> official FHS difference between /usr/local and /opt???
> 
> Umh... /usr/local is more traditional ;-) 
> 
> /usr/local/bin is in your default $PATH, /usr/local/lib in your
> ldconfig... It just feels more natural. 

  Just for the record, I vote for /usr/local/bin and /usr/local/lib,
say, /usr/local/lib/gems/1.8 or .../lib/ruby/gems...

  This is where system administrators all expect manually installed
software to go. There's no reason to treat gems differently.

>>> In any case, /var is meant for variable data - things which are
>>> prone to change by themselves (such as all kinds of databases). 
>> IIRC, the original reason for moving non-packaged gems out of /usr/lib
>> was that /usr should be mountable read-only (e.g., over a network), and
>> some gems tend to write into their own install directory.
> 
> Umh... If a gem requires writing something in its install directory
> once it is installed, something is fundamentally wrong. BTW, remember
> that gems (which are, after all, just libraries) are meant to be used
> systemwide, be it by administrators or by regular system users!

  Agree - we won't be able to do anything about this anyway, and I don't
think anyone would want to use a library that modifies its own
installation...

  Cheers,

	Vincent

PS: I CC a bit everyone here, I'm not quite sure who's subscribed and
who's not.
- --
Vincent Fourmond, Debian Developer
http://vince-debian.blogspot.com/
- -- pretty boring signature, isn't it ?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHaXFIx/UhwSKygsoRAkaFAJ9SZ+Q/17us5RbeOhbuAA2eAqyLAwCaA7G9
pFVRvRaI2ZV1u0YM9agfEEY=
=a9gj
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package rubygems. Full text and rfc822 format available.

Acknowledgement sent to Thomas Morgan <tmorgan@gdx.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. Full text and rfc822 format available.

Message #40 received at 448639@bugs.debian.org (full text, mbox):

From: Thomas Morgan <tmorgan@gdx.com>
To: 448639@bugs.debian.org
Subject: can we revisit the location of individual gem binaries?
Date: Wed, 18 Jun 2008 15:12:48 -0600
I am disappointed that rubygems 1.1.1 has moved gem binaries back  
into /var/lib/gems/1.8/bin/.

I find it somewhat annoying to have to deal with various gems'  
binaries being tucked away in a location that's not in the path. I've  
read the entire history to this particular bug report and understand  
the general concerns, I think.

I can easily agree with the concern over 1.0.1 putting gems in /usr/ 
bin/. But instead of burying them in /var/lib/gems/1.8/bin/ again, can  
we move them to /usr/local/bin/ ? That really is where sysadmins  
expect locally installed stuff to end up and I would suggest that  
manually installing individual gems falls within that expectation.

If there really is strong resistance to moving them to /usr/local/ 
bin/, then perhaps rubygems could be patched to read a config file in / 
etc somewhere that would describe where such binaries should end up? I  
would at least like to be able to easily override them to go into /usr/ 
local/bin with a single, one-time config option.

Thanks for your renewed consideration.

--t






Bug reassigned from package `rubygems' to `libgems-ruby'. Request was from Paul van Tilburg <paulvt@debian.org> to control@bugs.debian.org. (Wed, 16 Jul 2008 20:54:02 GMT) Full text and rfc822 format available.

Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Thu, 26 Aug 2010 17:54:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Byrum <clint@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Thu, 26 Aug 2010 17:54:03 GMT) Full text and rfc822 format available.

Message #47 received at 448639@bugs.debian.org (full text, mbox):

From: Clint Byrum <clint@ubuntu.com>
To: 448639@bugs.debian.org
Cc: ubuntu-devel@lists.ubuntu.com, rubygems-developers@rubyforge.org
Subject: rubygems and FHS compliance in Debian and Ubuntu
Date: Thu, 26 Aug 2010 10:51:34 -0700
ABSTRACT

This proposal seeks to clarify the current state of the rubygems package
in Debian and Ubuntu, and provide a clear path toward full FHS compliance
and usability for users.

CURRENT STATUS

Rubygems is a tool used by ruby users to download and install ruby
modules in much the same way CPAN works for Perl, and pypi/easy_install
works for python. A developer may create a "gem" that encompasses their
software module, and publish it into the rubygems repository. Ruby users
have grown to use this as their primary source of software modules,
and as such, it is so important that it is now included with Ruby 1.9,
the latest stable release of Ruby.

One component of these modules is executable scripts. These scripts are
provided to users to perform essential functions related to whatever
module they are packaged with, or sometimes the script itself is the
entire point of the module, as is the case with the 'rails' gem, which
installs a web framework and application server. Rubygems actually
generates the files that go in to its "bindir" so that they are pointed
at the desired ruby binary.

In the upstream default install of rubygems, the default location for
these binaries and rubygems library files is /usr/bin, and /usr/lib
respectively. This places the binaries in the default shell path for most
FHS systems, so that users can have an experience something like this:

$ sudo gem install rails [... gem downloads and installs rails ... ]
$ rails my-facebook-killer-app/ [... A skeleton of a rails app is
created ...  ... I Start hacking on my-facebook-killer-app ...]

A few years ago, these two bugs were filed, and fixed, in Debian:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=480250
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=458987

These were fixed by having rubygems change its default path, to
/var/lib/gems/$ruby_version

This definitely address the users' issue, which was basically "I don't
want the rubygems package manager to be able to easily conflict with
the debian package manager."

However, this introduced an incompatibility with the FHS definition of
the purpose of /var[1].

"/var contains variable data files. This includes spool directories and
files, administrative and logging data, and transient and temporary files.

Some portions of /var are not shareable between different systems. For
instance, /var/log, /var/lock, and /var/run. Other portions may be shared,
notably /var/mail, /var/cache/man, /var/cache/fonts, and /var/spool/news.

/var is specified here in order to make it possible to mount /usr
read-only. Everything that once went into /usr that is written to during
system operation (as opposed to installation and software maintenance)
must be in /var."

And further, the purpose of /var/lib

"This hierarchy holds state information pertaining to an application or
the system. State information is data that programs modify while they
run, and that pertains to one specific host. Users must never need to
modify files in /var/lib to configure a package's operation.

State information is generally used to preserve the condition of an
application (or a group of inter-related applications) between invocations
and between different instances of the same application. State information
should generally remain valid after a reboot, should not be logging
output, and should not be spooled data."

While the terms used are certainly open to interpretation, its difficult
to argue that executable scripts and libraries constitute "state
information that programs modify while they run and that pertains to
one specific host".

This potential issue with FHS compliance means rubygems may be in
violation of Section 9.1 of the debian policy manual:

http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.1

Whats more, users do not expect to find executable scripts in /var. The
default path on current Debian systems is as follows:

/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games

and on Ubuntu:

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games

Adding entries to the path is a non-trivial activity that most users
won't do in a way that makes their system maintainable or flexible over
a long period of time.

PROPOSED SOLUTION

Rubygems in Debian and Ubuntu should place gems in /usr/local/lib/gems
and gem executables in /usr/local/bin.

FHS defines the purpose of /usr/local as such:

"The /usr/local hierarchy is for use by the system administrator when
installing software locally. It needs to be safe from being overwritten
when the system software is updated. It may be used for programs and
data that are shareable amongst a group of hosts, but not found in /usr.

Locally installed software must be placed within /usr/local rather than
/usr unless it is being installed to replace or upgrade software in /usr."

Placing installed gems in /usr/local/lib/gems and /usr/local/bin, would
allow rubygems to maintain FHS compliance, and avoid the problem of
users accidentally overwriting dpkg installed files. This would seem a
"win win" for all issues involved.

Because the default path in the shell on most systems includes
/usr/local/bin, this would ease users' experience, and allow system
administrators to use both rubygems and dpkg/apt in the same way,
without having them conflict.

--

[1] http://www.pathname.com/fhs/pub/fhs-2.3.html





Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#448639; Package libgems-ruby. (Sat, 28 Aug 2010 02:54:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daigo Moriwaki <daigo@debian.org>:
Extra info received and forwarded to list. (Sat, 28 Aug 2010 02:54:02 GMT) Full text and rfc822 format available.

Message #52 received at 448639@bugs.debian.org (full text, mbox):

From: Daigo Moriwaki <daigo@debian.org>
To: Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Subject: Re: Bug#448639: rubygems and FHS compliance in Debian and Ubuntu
Date: Sat, 28 Aug 2010 11:21:46 +0900
Clint,

Clint Byrum wrote:
> In the upstream default install of rubygems, the default location for
> these binaries and rubygems library files is /usr/bin, and /usr/lib
> respectively. This places the binaries in the default shell path for most
> FHS systems, so that users can have an experience something like this:
> 
> $ sudo gem install rails [... gem downloads and installs rails ... ]
> $ rails my-facebook-killer-app/ [... A skeleton of a rails app is
> created ...  ... I Start hacking on my-facebook-killer-app ...]

My opinion is opposite. I'd like to require users a manual intervention to
execute binaries from gems due to security concern. Users might think that gem
install something is very similar to apt-get install something. However,
Rubygems' security culture differs from Debian's. Signed gems are not popular.
Imagine that a gem (located in a server or through network) is attacked to
include a malicious executable named 'ls', which then installs in your
/usr/local/bin.

In addition, I'd like to make room in /usr/local/bin for local installations,
such as setup.rb, make && make install etc... I think that I have made success
in this point since nobody has ever claimed that /var/lib/gems is in his/her way.


> However, this introduced an incompatibility with the FHS definition of
> the purpose of /var[1].

I agree with the primary purpose of /var that you mentioned. But I can not find
any better place to install gems files with two points above satisfied.

Regards,
Daigo

-- 
Daigo Moriwaki
daigo at debian dot org




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Sat, 28 Aug 2010 19:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam Jacob <adam@opscode.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Sat, 28 Aug 2010 19:03:03 GMT) Full text and rfc822 format available.

Message #57 received at 448639@bugs.debian.org (full text, mbox):

From: Adam Jacob <adam@opscode.com>
To: 448639@bugs.debian.org
Cc: ubuntu-devel@lists.ubuntu.com, rubygems-developers@rubyforge.org
Subject: +1 for /usr/local
Date: Sat, 28 Aug 2010 11:58:04 -0700
This has been one of my longest standing issues with Ruby on Debian.

As a systems administrator, having libraries appear in /var/lib/gems,
and binaries in /var/lib/gems/1.8/bin is incredibly confusing.  When I
install a rubygem on a system, I know I'm stepping outside of the
bounds of Debian's purview - I'm not using apt or dpkg, and I'm
venturing into the world of external package management.
Unfortunately, the choice makes it so I loose on two fronts: my
expectation is that things will wind up in /usr/local (as that's what
happens when I use CPAN, pypi, or easy_install), but they don't.
Secondly, unless the maintainer of the application (rails, chef, etc.)
knows the current status of rubygems on Debian and warns me up front,
I have no way of discovering a-priori that the changes to my system
are in /var/lib/gems.

As an active member of the ruby community, I constantly have to caveat
that users on Debian will get a sub-par user experience if they use
the community standard distribution mechanism.  Most often, our advice
is simply to install the upstream rubygems package from source on
every Debian system - so that the behavior they experience at least be
in line with every piece of documentation generated by the ruby
community.  Unfortunately, this has serious drawbacks - Debian policy
exists for a reason, and it makes the user experience better.  In this
case, it makes it significantly worse.  The reputation within the
community is widely that rubygems on Debian is "broken".

As a developer of a popular application built with ruby (Chef,) we
actively maintain and support packages built specifically for Debian.
I think it's clear to everyone that this should be the preferred path
for installation on a Debian machine - it ensures compliance with the
policy, and a smooth and predictable user experience.  In this case
we're talking about what happens when an administrator explicitly
decides to take another route - just like when they use CPAN or pypi.
The reasonable thing to do here is to give them the experience that
they expect, while still keeping the base system clean for the future
- and to me, that means /usr/local.

The comments raised about the possibility of rubygems that install
binaries that replicate common system utilities is true of any outside
package management system, or any random tarball installed on the
system.  We don't alter CPAN, or tar.  Additionally, many rubygems no
longer even ship with setup.rb, and even fewer will as we move to 1.9,
where rubygems is a standard part of ruby.

Please make the defaults be /usr/local.  At the very least, make the
Gem binary path be /usr/locall/bin.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Sat, 28 Aug 2010 19:18:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Ash Berlin <ashberlin@gmail.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Sat, 28 Aug 2010 19:18:03 GMT) Full text and rfc822 format available.

Message #62 received at 448639@bugs.debian.org (full text, mbox):

From: Ash Berlin <ashberlin@gmail.com>
To: 448639@bugs.debian.org
Subject: 1 for /usr/local
Date: Sat, 28 Aug 2010 20:15:14 +0100
I agree with Adam's points. Primarily it seems very odd to me that `gem` behaves this way when `cpan` does not.

-ash



Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Sat, 28 Aug 2010 19:33:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Sat, 28 Aug 2010 19:33:04 GMT) Full text and rfc822 format available.

Message #67 received at 448639@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: 448639@bugs.debian.org
Subject: Taking this to the CTTE?
Date: Sat, 28 Aug 2010 21:31:03 +0200
Hi Daigo,

using /var/lib/gems is really quite annoying, and I have meant to write
something along the lines of what Clint Byrum wrote a few messages ago.
Sure, using /usr/local isn't ideal, but that's a choice that's up to the
local system administrator; what you're effectively doing is just
forcing people to jump through a hoop and having to add
/var/lib/gems/bin to the default path, which is really quite silly.  The
lack of consistency with what CPAN does is also annoying as we're making
a distribution, not just packaging a bunch of software.

So, please, please change this.  If you don't want to change this, I'll
take this to the CTTE so they can rule on this.

Regards,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#448639; Package libgems-ruby. (Sun, 29 Aug 2010 01:27:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daigo Moriwaki <daigo@debian.org>:
Extra info received and forwarded to list. (Sun, 29 Aug 2010 01:27:03 GMT) Full text and rfc822 format available.

Message #72 received at 448639@bugs.debian.org (full text, mbox):

From: Daigo Moriwaki <daigo@debian.org>
To: Adam Jacob <adam@opscode.com>, 448639@bugs.debian.org
Cc: ubuntu-devel@lists.ubuntu.com, rubygems-developers@rubyforge.org
Subject: Re: Bug#448639: +1 for /usr/local
Date: Sun, 29 Aug 2010 10:26:14 +0900
Adam,

Adam Jacob wrote:
> policy, and a smooth and predictable user experience.  In this case
> we're talking about what happens when an administrator explicitly
> decides to take another route - just like when they use CPAN or pypi.

I have little idea on CPAN or pypi culture. Are unsigned packages (i.e. no
infrastructure checking packages consistency) common on CPAN or pypi? Don't CPAN
or pypi users have no security concern?

Regards,
Daigo

-- 
Daigo Moriwaki
daigo at debian dot org




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Sun, 29 Aug 2010 05:21:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam Jacob <adam@opscode.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Sun, 29 Aug 2010 05:21:02 GMT) Full text and rfc822 format available.

Message #77 received at 448639@bugs.debian.org (full text, mbox):

From: Adam Jacob <adam@opscode.com>
To: Daigo Moriwaki <daigo@debian.org>
Cc: "448639@bugs.debian.org" <448639@bugs.debian.org>, "ubuntu-devel@lists.ubuntu.com" <ubuntu-devel@lists.ubuntu.com>, "rubygems-developers@rubyforge.org" <rubygems-developers@rubyforge.org>
Subject: Re: Bug#448639: +1 for /usr/local
Date: Sat, 28 Aug 2010 22:20:07 -0700
On Aug 28, 2010, at 6:26 PM, Daigo Moriwaki <daigo@debian.org> wrote:
> I have little idea on CPAN or pypi culture. Are unsigned packages (i.e. no
> infrastructure checking packages consistency) common on CPAN or pypi? Don't CPAN
> or pypi users have no security concern?

They do not have any kind of signing, as far as I know. In all cases, they have basic security schemes primarily at the point at which maintainers upload packages.

When end users install a gem, they take the responsibility for understanding the contents.  It truly is no different than installing a source tarball in that regard.  

Thank you for being open minded and willing to engage on this topic, Daigo, and for the work you put in to making ruby work well on debian.

Adam



Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Sun, 29 Aug 2010 05:51:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Joshua Timberman <joshua@opscode.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Sun, 29 Aug 2010 05:51:02 GMT) Full text and rfc822 format available.

Message #82 received at 448639@bugs.debian.org (full text, mbox):

From: Joshua Timberman <joshua@opscode.com>
To: 448639@bugs.debian.org
Subject: +1 for /usr/local
Date: Sat, 28 Aug 2010 23:46:44 -0600
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I agree with Clint and Adam. While I certainly know how to set my PATH, I still install RubyGems from source on Debian (and Ubuntu) systems because the default package behaves in a way contrary to what I expect.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (Darwin)

iEYEARECAAYFAkx59EQACgkQO97WSdVpzT1uCwCgkm3Trf2Uj3B/Z60GhLQUINFr
tvEAn1AP5ySIlJb0hK7pmsvb4kAveikC
=/mcb
-----END PGP SIGNATURE-----




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Sun, 29 Aug 2010 06:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Darrin Eden <darrin@heavywater.ca>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Sun, 29 Aug 2010 06:09:03 GMT) Full text and rfc822 format available.

Message #87 received at 448639@bugs.debian.org (full text, mbox):

From: Darrin Eden <darrin@heavywater.ca>
To: 448639@bugs.debian.org
Subject: +1 for /usr/local
Date: Sat, 28 Aug 2010 23:07:55 -0700
I would like to register my support for RubyGems to be FHS-compliant and install in /usr/local. As a systems administrator I currently spend a significant effort, without adding value, working around Debian's differing RubyGems implementation.



Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 01:42:57 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jeffrey Hulten <jeffh@automatedlabs.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 01:42:57 GMT) Full text and rfc822 format available.

Message #92 received at 448639@bugs.debian.org (full text, mbox):

From: Jeffrey Hulten <jeffh@automatedlabs.com>
To: 448639@bugs.debian.org
Subject: +1 for /usr/local
Date: Sun, 29 Aug 2010 18:33:55 -0700
[Message part 1 (text/plain, inline)]
For me, when I install any non-debian package (gem, easy_install, or
self-compiled) it is a user install. /usr/local makes sense to me.

-- 
Jeffrey Hulten
Principal Consultant at Automated Labs, LLC
jeffh@automatedlabs.com  206-923-8246
[Message part 2 (text/html, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 12:45:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to kapouer@melix.org:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 12:45:03 GMT) Full text and rfc822 format available.

Message #97 received at 448639@bugs.debian.org (full text, mbox):

From: Jérémy Lal <kapouer@melix.org>
To: Daigo Moriwaki <daigo@debian.org>, 448639@bugs.debian.org
Subject: Re: [DRE-maint] Bug#448639: rubygems and FHS compliance in Debian and Ubuntu
Date: Mon, 30 Aug 2010 14:41:56 +0200
Hi,
i feel concerned with this discussion as i'm packaging npm, a nodejs package manager.
First draft is using /var/lib/npm (only when user is root), similar to gem does.
However my mentor and me felt it was sub-optimal.
I'd be glad a common census arise around those questions.

Regards,
Jérémy Lal





Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 13:39:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 13:39:04 GMT) Full text and rfc822 format available.

Message #102 received at 448639@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Tollef Fog Heen <tfheen@err.no>, 448639@bugs.debian.org
Cc: clint@ubuntu.com
Subject: Re: Bug#448639: Taking this to the CTTE?
Date: Mon, 30 Aug 2010 15:37:47 +0200
On 28/08/10 at 21:31 +0200, Tollef Fog Heen wrote:
> Hi Daigo,
> 
> using /var/lib/gems is really quite annoying, and I have meant to write
> something along the lines of what Clint Byrum wrote a few messages ago.
> Sure, using /usr/local isn't ideal, but that's a choice that's up to the
> local system administrator; what you're effectively doing is just
> forcing people to jump through a hoop and having to add
> /var/lib/gems/bin to the default path, which is really quite silly.  The
> lack of consistency with what CPAN does is also annoying as we're making
> a distribution, not just packaging a bunch of software.
> 
> So, please, please change this.  If you don't want to change this, I'll
> take this to the CTTE so they can rule on this.

While I support the idea of using /usr/local (I even submitted this bug
back in 2007), I find it incredible that you threaten to take this to
the TC.

There has been basically no activity on this bug between december 2007
and now. On August 26th, a Canonical employee restarts that discussion,
and two days later, another Canonical employee threatens to take it to
the TC?  Come on! Can't we have at least one week of peaceful discussion
before you light up the flames?

Also, I don't see anything in the bug report about the way you expect
the transition from /var/lib to /usr/local to happen. It would be great
to investigate this and propose something in the form of a patch if this
issue has suddenly become so urgent for you.

Lucas




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 14:51:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Olsen <tim@brooklynpenguin.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 14:51:03 GMT) Full text and rfc822 format available.

Message #107 received at 448639@bugs.debian.org (full text, mbox):

From: Tim Olsen <tim@brooklynpenguin.com>
To: Tollef Fog Heen <tfheen@err.no>, 448639@bugs.debian.org
Subject: Re: Bug#448639: Taking this to the CTTE?
Date: Mon, 30 Aug 2010 10:48:04 -0400
On 08/28/2010 03:31 PM, Tollef Fog Heen wrote:
> 
> Hi Daigo,
> 
> using /var/lib/gems is really quite annoying, and I have meant to write
> something along the lines of what Clint Byrum wrote a few messages ago.
> Sure, using /usr/local isn't ideal, but that's a choice that's up to the
> local system administrator; what you're effectively doing is just
> forcing people to jump through a hoop and having to add
> /var/lib/gems/bin to the default path, which is really quite silly.  The
> lack of consistency with what CPAN does is also annoying as we're making
> a distribution, not just packaging a bunch of software.

Actually, the directory to add to your PATH is
/var/lib/gems/RUBY_VERSION/bin.  I'm saying this not to split hairs, but
to point out that the current system allows some flexibility with regard
to Ruby 1.8 and 1.9.1.  I can install gems for both 1.8 and 1.9.1 and
then switch easily between the two by changing my PATH.  How do you
propose allowing for executables for both Ruby 1.8 and Ruby 1.9.1
versions of the same gem to be installed simultaneously if all gem
executables are going into /usr/local/bin ?   I think this is currently
an important issue as both Ruby 1.8 and 1.9.x are actively used and it
appears that it's going to take a while until 1.9.x is widely adopted.

Tim






Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 15:03:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Byrum <clint@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 15:03:03 GMT) Full text and rfc822 format available.

Message #112 received at 448639@bugs.debian.org (full text, mbox):

From: Clint Byrum <clint@ubuntu.com>
To: Lucas Nussbaum <lucas@lucas-nussbaum.net>
Cc: Tollef Fog Heen <tfheen@err.no>, 448639@bugs.debian.org
Subject: Re: Bug#448639: Taking this to the CTTE?
Date: Mon, 30 Aug 2010 08:01:49 -0700
On Aug 30, 2010, at 6:37 AM, Lucas Nussbaum wrote:

> On 28/08/10 at 21:31 +0200, Tollef Fog Heen wrote:
>> Hi Daigo,
>> 
>> using /var/lib/gems is really quite annoying, and I have meant to write
>> something along the lines of what Clint Byrum wrote a few messages ago.
>> Sure, using /usr/local isn't ideal, but that's a choice that's up to the
>> local system administrator; what you're effectively doing is just
>> forcing people to jump through a hoop and having to add
>> /var/lib/gems/bin to the default path, which is really quite silly.  The
>> lack of consistency with what CPAN does is also annoying as we're making
>> a distribution, not just packaging a bunch of software.
>> 
>> So, please, please change this.  If you don't want to change this, I'll
>> take this to the CTTE so they can rule on this.
> 
> While I support the idea of using /usr/local (I even submitted this bug
> back in 2007), I find it incredible that you threaten to take this to
> the TC.
> 

Agreed Lucas, Daigo has done his best and remained open to this discussion,
so I hope we can all agree to take this off the table.

> There has been basically no activity on this bug between december 2007
> and now. On August 26th, a Canonical employee restarts that discussion,
> and two days later, another Canonical employee threatens to take it to
> the TC?  Come on! Can't we have at least one week of peaceful discussion
> before you light up the flames?
> 

One correction, I believe Tollef left Canonical in 2008. I know I just met
him for the first time in June, and he was no longer with the company at
that time.

> Also, I don't see anything in the bug report about the way you expect
> the transition from /var/lib to /usr/local to happen. It would be great
> to investigate this and propose something in the form of a patch if this
> issue has suddenly become so urgent for you.
> 

I'd like to see us get through the theoretical and philosophical decision
before we start getting deep into any implementation, as I think that 
would be getting way ahead of ourselves. However, I think 
/var/lib/gems/$ruby_version should simply remain in ruby's path for this
version, and at some point, a "Breaks:" can be added when we remove that.




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 15:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Olsen <tim@brooklynpenguin.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 15:09:02 GMT) Full text and rfc822 format available.

Message #117 received at 448639@bugs.debian.org (full text, mbox):

From: Tim Olsen <tim@brooklynpenguin.com>
To: Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Cc: ubuntu-devel@lists.ubuntu.com, rubygems-developers@rubyforge.org
Subject: Re: Bug#448639: rubygems and FHS compliance in Debian and Ubuntu
Date: Mon, 30 Aug 2010 10:39:32 -0400
On 08/26/2010 01:51 PM, Clint Byrum wrote:
> FHS defines the purpose of /usr/local as such:
> 
> "The /usr/local hierarchy is for use by the system administrator when
> installing software locally. It needs to be safe from being overwritten
> when the system software is updated. It may be used for programs and
> data that are shareable amongst a group of hosts, but not found in /usr.

Let's say hypothetically that we change Debian's rubygems to use
/usr/local.  Is it guaranteed that the rubygems will not touch
/usr/local when rubygems is upgraded?  If not, then /usr/local would not
be "safe from being overwritten when the system software is updated."

Tim




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 15:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Byrum <clint@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 15:51:06 GMT) Full text and rfc822 format available.

Message #122 received at 448639@bugs.debian.org (full text, mbox):

From: Clint Byrum <clint@ubuntu.com>
To: tim@brooklynpenguin.com
Cc: 448639@bugs.debian.org, Tollef Fog Heen <tfheen@err.no>
Subject: Re: Debian Bugs information: detailed logs for Bug#448639
Date: Mon, 30 Aug 2010 08:46:24 -0700
On Aug 30, 2010, at 8:21 AM, Tim Olsen wrote:

> On 08/28/2010 03:31 PM, Tollef Fog Heen wrote:
>> 
>>  what you're effectively doing is just
>> forcing people to jump through a hoop and having to add
>> /var/lib/gems/bin to the default path, which is really quite silly.  
> 
> Actually, the directory to add to your PATH is
> /var/lib/gems/RUBY_VERSION/bin.  I'm saying this not to split hairs, but
> to point out that the current system allows some flexibility with regard
> to Ruby 1.8 and 1.9.1.  I can install gems for both 1.8 and 1.9.1 and
> then switch easily between the two by changing my PATH.  How do you
> propose allowing for executables for both Ruby 1.8 and Ruby 1.9.1
> versions of the same gem to be installed simultaneously if all gem
> executables are going into /usr/local/bin ?   I think this is currently
> an important issue as both Ruby 1.8 and 1.9.x are actively used and it
> appears that it's going to take a while until 1.9.x is widely adopted.
> 

Hi Tim, thanks for your insight on this,

This is an interesting limitation of the proposal to move things to
/usr/local/bin. I'm not sure its something Debian should try and solve
though.

As Adam Jacob pointed out earlier, the docs for any given gem are
written in such a way that they expect these binaries in the path. So
consequently, the authors of the gems will expect that the binaries will
conflict between gem1.8 and gem1.9.

rubygems is not an end user tool, it is a development tool. As such,
it has sharp jagged edges that let you do things like this. I'm all
for making sure users are protected from themselves, but gaining root
privileges means you are taking responsibility for your actions, meaning
you should read through the docs of the the things you're running and
understand the gems you're installing.

Its cool that right now there's no conflict between 1.8 and 1.9 installed
gems. I'm sure its saved a few users from themselves. However, it has
confused many, many more users and left the ruby dev community frustrated,
so while I see the merit in leaving it as it is, I see more merit in
changing it.





Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 16:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Byrum <clint@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 16:09:03 GMT) Full text and rfc822 format available.

Message #127 received at 448639@bugs.debian.org (full text, mbox):

From: Clint Byrum <clint@ubuntu.com>
To: daigo@debian.org
Cc: 448639@bugs.debian.org
Subject: Re: Debian Bugs information: detailed logs for Bug#448639
Date: Mon, 30 Aug 2010 09:06:08 -0700
Hi Daigo, thanks so much for your thoughts on this matter,

On Aug 30, 2010, at 8:21 AM, Daigo Moriwaki wrote:

> Clint Byrum wrote:
>> In the upstream default install of rubygems, the default location for
>> these binaries and rubygems library files is /usr/bin, and /usr/lib
>> respectively. This places the binaries in the default shell path for most
>> FHS systems, so that users can have an experience something like this:
>> 
>> $ sudo gem install rails [... gem downloads and installs rails ... ]
>> $ rails my-facebook-killer-app/ [... A skeleton of a rails app is
>> created ...  ... I Start hacking on my-facebook-killer-app ...]
> 
> My opinion is opposite. I'd like to require users a manual intervention to
> execute binaries from gems due to security concern. Users might think that gem
> install something is very similar to apt-get install something. However,
> Rubygems' security culture differs from Debian's. Signed gems are not popular.
> Imagine that a gem (located in a server or through network) is attacked to
> include a malicious executable named 'ls', which then installs in your
> /usr/local/bin.
> 

I agree that users need to be protected from insecure code being inserted
into their environment. However, I feel that this is the responsibility
of the system administrator.

As a sysadmin, If I download a tarball, I must take the responsibility to
check for a signature.  If it is signed, I must take the responsibility
to verify that this key is in my trust network. If no such signature
exists, or if I cannot trust the author, I must make a best effort to
review the build system and code before placing it on my system.

However, we all know that system administrators are busy, and do not have
time for this, so many will simply refuse to install using tarballs,
trusting instead the distributor of software they have chosen (such as
Debian), or will skip this step, endangering their users. But that is
their choice, it is their system and they must choose what level of risk
they take. Security is not a state of being, but a process involving
risk management.

rubygems is no different than wget, tar, make, and gcc. These are all
just developer tools, and as such, can be dangerous. Right now, if an
admin makes a decision to install gems in /var/lib/gems/1.8/bin, and
then adds that directory to the default user path, users are at risk,
just as they would be if the programs were in /usr/local/bin.


> In addition, I'd like to make room in /usr/local/bin for local installations,
> such as setup.rb, make && make install etc... I think that I have made success
> in this point since nobody has ever claimed that /var/lib/gems is in his/her way
> .
> 

Daigo, I think you have done an amazing job with rubygems thus far,
and we should all be thankful for the hard work you've put into
maintaining it. This directory layout does make a lot of sense, in a lot
of ways. However, it is clear to me by talking with the ruby community,
and reading the comments added to this bug report, that this scheme has
caused issues, and so needs to be reviewed and possibly changed.


> 
>> However, this introduced an incompatibility with the FHS definition of
>> the purpose of /var[1].
> 
> I agree with the primary purpose of /var that you mentioned. But I can not find
> any better place to install gems files with two points above satisfied.

I think that by requiring FHS compliance, and choosing a default path, 
Debian policy has defined a small, acceptable level of risk for users.



Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 17:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Olsen <tim@brooklynpenguin.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 17:00:07 GMT) Full text and rfc822 format available.

Message #132 received at 448639@bugs.debian.org (full text, mbox):

From: Tim Olsen <tim@brooklynpenguin.com>
To: Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Cc: Tollef Fog Heen <tfheen@err.no>
Subject: Re: Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Date: Mon, 30 Aug 2010 12:58:38 -0400
On 08/30/2010 11:46 AM, Clint Byrum wrote:
> rubygems is not an end user tool, it is a development tool. As such,
> it has sharp jagged edges that let you do things like this. I'm all
> for making sure users are protected from themselves, but gaining root
> privileges means you are taking responsibility for your actions, meaning
> you should read through the docs of the the things you're running and
> understand the gems you're installing.

I am a developer and being able to switch between Ruby 1.8 and Ruby
1.9.1 gems is important for me.  For example, I use Rubygems-installed
rake to run my automated tests.  All I have to do to see if my tests
work on a different version of Ruby is to update my PATH.  Making sure
that a Ruby library works for both Ruby 1.8 and 1.9 is an important
activity for a Ruby library developer nowadays.

One minor point: you do not need to be root to modify /usr/local.  On
default Debian installs (but not in Ubuntu), you only need to be in the
staff group.

> 
> Its cool that right now there's no conflict between 1.8 and 1.9 installed
> gems. I'm sure its saved a few users from themselves. However, it has
> confused many, many more users and left the ruby dev community frustrated,
> so while I see the merit in leaving it as it is, I see more merit in
> changing it.
> 

As a Ruby library developer, installing Ruby gem executables in
/usr/local/bin would frustrate me more because it would be more
difficult to test on both Ruby 1.8 and Ruby 1.9.

Besides, I'm not convinced that using /usr/local is itself
FHS-compliant.  (I've sent an email earlier about this but I haven't
seen it go through yet).  If upgrading the rubygems package may modify
/usr/local then that violates the FHS: "It needs to be safe from being
overwritten when the system software is updated."

Tim





Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 17:42:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam Jacob <adam@opscode.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 17:42:03 GMT) Full text and rfc822 format available.

Message #137 received at 448639@bugs.debian.org (full text, mbox):

From: Adam Jacob <adam@opscode.com>
To: tim@brooklynpenguin.com, clint@ubuntu.com, 448639@bugs.debian.org
Subject: Re: Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Date: Mon, 30 Aug 2010 10:38:33 -0700
Tim Olsen wrote:

> I am a developer and being able to switch between Ruby 1.8 and Ruby
> 1.9.1 gems is important for me.  For example, I use Rubygems-installed
> rake to run my automated tests.  All I have to do to see if my tests
> work on a different version of Ruby is to update my PATH.  Making sure
> that a Ruby library works for both Ruby 1.8 and 1.9 is an important
> activity for a Ruby library developer nowadays.
>
> One minor point: you do not need to be root to modify /usr/local.  On
> default Debian installs (but not in Ubuntu), you only need to be in the
> staff group.

While this is indeed convenient for the use case, I would argue it's
totally out of whack with the expectations that anyone coming to
Debian from the Ruby community expects.  The majority of people
installing rubygems are doing so because they are using the gem - not
because they are doing a development cycle.  The development use case
has many other options (rvm, for one) that solve the problem - the
end-user case does not, as only Debian policy can fix it. So, I feel
your pain, but there is a greatest good argument here in favor of
/usr/local.

> Besides, I'm not convinced that using /usr/local is itself
> FHS-compliant.  (I've sent an email earlier about this but I haven't
> seen it go through yet).  If upgrading the rubygems package may modify
> /usr/local then that violates the FHS: "It needs to be safe from being
> overwritten when the system software is updated."

Upgrading rubygems by itself would not update /usr/local, as it is
packaged directly within Debian - so it's entirely within our control
as to whether or not it updates anything in /usr/local.  To my
knowledge, there has never been a rubygems upgrade that forces an
update of installed gems automatically, which would be the only case
in which this might be in jeopardy.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 17:42:05 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam Jacob <adam@opscode.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 17:42:05 GMT) Full text and rfc822 format available.

Message #142 received at 448639@bugs.debian.org (full text, mbox):

From: Adam Jacob <adam@opscode.com>
To: Tim Olsen <tim@brooklynpenguin.com>, Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Subject: On transition
Date: Mon, 30 Aug 2010 10:40:06 -0700
I believe the patch for transitioning to /usr/local can include the
previous GEM_PATH, which should make the transition relatively smooth
for existing users.

Adam

-- 
Opscode, Inc.
Adam Jacob, CTO
T: (206) 508-7449 E: adam@opscode.com




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 18:00:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tim Olsen <tim@brooklynpenguin.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 18:00:07 GMT) Full text and rfc822 format available.

Message #147 received at 448639@bugs.debian.org (full text, mbox):

From: Tim Olsen <tim@brooklynpenguin.com>
To: Adam Jacob <adam@opscode.com>
Cc: clint@ubuntu.com, 448639@bugs.debian.org
Subject: Re: Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Date: Mon, 30 Aug 2010 13:58:20 -0400
On 08/30/2010 01:38 PM, Adam Jacob wrote:
> Tim Olsen wrote:
> 
>> I am a developer and being able to switch between Ruby 1.8 and Ruby
>> 1.9.1 gems is important for me.  For example, I use Rubygems-installed
>> rake to run my automated tests.  All I have to do to see if my tests
>> work on a different version of Ruby is to update my PATH.  Making sure
>> that a Ruby library works for both Ruby 1.8 and 1.9 is an important
>> activity for a Ruby library developer nowadays.
>>
>> One minor point: you do not need to be root to modify /usr/local.  On
>> default Debian installs (but not in Ubuntu), you only need to be in the
>> staff group.
> 
> While this is indeed convenient for the use case, I would argue it's
> totally out of whack with the expectations that anyone coming to
> Debian from the Ruby community expects.  The majority of people
> installing rubygems are doing so because they are using the gem - not
> because they are doing a development cycle.  The development use case
> has many other options (rvm, for one) that solve the problem - the
> end-user case does not, as only Debian policy can fix it. So, I feel
> your pain, but there is a greatest good argument here in favor of
> /usr/local.

Ok.  I agree with you here now.  I'll just have switch to using rvm or
the like.

> 
>> Besides, I'm not convinced that using /usr/local is itself
>> FHS-compliant.  (I've sent an email earlier about this but I haven't
>> seen it go through yet).  If upgrading the rubygems package may modify
>> /usr/local then that violates the FHS: "It needs to be safe from being
>> overwritten when the system software is updated."
> 
> Upgrading rubygems by itself would not update /usr/local, as it is
> packaged directly within Debian - so it's entirely within our control
> as to whether or not it updates anything in /usr/local.  To my
> knowledge, there has never been a rubygems upgrade that forces an
> update of installed gems automatically, which would be the only case
> in which this might be in jeopardy.

What I was more thinking of was if there was a change in how rubygems
organizes things under /usr/local.  Lucas proposed storing gems under
/usr/local/lib/ruby/gems/1.8.  But if rubygems needs to move things
around upon an upgrade, then that's technically a violation.  Even
setting up directories under /usr/local upon rubygems installation might
be considered a violation.  One possibility is to store everything *but*
executables outside of /usr/local.

Tim

> 
> Adam
> 





Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 18:03:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Tollef Fog Heen <tfheen@err.no>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 18:03:02 GMT) Full text and rfc822 format available.

Message #152 received at 448639@bugs.debian.org (full text, mbox):

From: Tollef Fog Heen <tfheen@err.no>
To: Lucas Nussbaum <lucas@lucas-nussbaum.net>
Cc: 448639@bugs.debian.org, clint@ubuntu.com
Subject: Re: Bug#448639: Taking this to the CTTE?
Date: Mon, 30 Aug 2010 19:59:59 +0200
]] Lucas Nussbaum 

| On 28/08/10 at 21:31 +0200, Tollef Fog Heen wrote:
| > Hi Daigo,
| > 
| > using /var/lib/gems is really quite annoying, and I have meant to write
| > something along the lines of what Clint Byrum wrote a few messages ago.
| > Sure, using /usr/local isn't ideal, but that's a choice that's up to the
| > local system administrator; what you're effectively doing is just
| > forcing people to jump through a hoop and having to add
| > /var/lib/gems/bin to the default path, which is really quite silly.  The
| > lack of consistency with what CPAN does is also annoying as we're making
| > a distribution, not just packaging a bunch of software.
| > 
| > So, please, please change this.  If you don't want to change this, I'll
| > take this to the CTTE so they can rule on this.
| 
| While I support the idea of using /usr/local (I even submitted this bug
| back in 2007), I find it incredible that you threaten to take this to
| the TC.

Threaten?  It's the place to take technical arguments that can't be
resolved by discussion, and this has been a long-standing argument with
little movement on either side.

| There has been basically no activity on this bug between december 2007
| and now. On August 26th, a Canonical employee restarts that discussion,
| and two days later, another Canonical employee threatens to take it to
| the TC?  Come on! Can't we have at least one week of peaceful discussion
| before you light up the flames?

I left Canonical years ago, and I don't see why somebody's employment
would be relevant at all.  I'm, as you can see, writing from my personal
email address.

| Also, I don't see anything in the bug report about the way you expect
| the transition from /var/lib to /usr/local to happen. It would be great
| to investigate this and propose something in the form of a patch if this
| issue has suddenly become so urgent for you.

That is an implementation detail, and assuming we can agree on moving to
/usr/local, I'm sure deciding on how the transition should work is
doable.  It's pointless to start writing patches before there's
agreement what needs to be changed how.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 18:27:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Adam Jacob <adam@opscode.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 18:27:06 GMT) Full text and rfc822 format available.

Message #157 received at 448639@bugs.debian.org (full text, mbox):

From: Adam Jacob <adam@opscode.com>
To: Tim Olsen <tim@brooklynpenguin.com>
Cc: "clint@ubuntu.com" <clint@ubuntu.com>, "448639@bugs.debian.org" <448639@bugs.debian.org>
Subject: Re: Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Date: Mon, 30 Aug 2010 11:26:12 -0700
On Aug 30, 2010, at 10:58 AM, Tim Olsen <tim@brooklynpenguin.com> wrote:
> What I was more thinking of was if there was a change in how rubygems
> organizes things under /usr/local.  Lucas proposed storing gems under
> /usr/local/lib/ruby/gems/1.8.  But if rubygems needs to move things
> around upon an upgrade, then that's technically a violation.  Even
> setting up directories under /usr/local upon rubygems installation might
> be considered a violation.  One possibility is to store everything *but*
> executables outside of /usr/local.

I think that would be acceptable, but I'm not sure it's necessary.  The on disk gem format (with gems under a gems dir in an arch specific path) has been pretty consistent.  

If CPAN did this, I imagine we would still ship the new version, and just warn users about the breakage on upgrade.  With 1.9 shipping rubygems in the core ruby distribution, I think we can be safe in saying if the upstream does this, users are on their own: they choose an external package system, so they can suffer the consequences of a fickle upstream. 

Best,
Adam



Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Mon, 30 Aug 2010 20:51:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Mon, 30 Aug 2010 20:51:06 GMT) Full text and rfc822 format available.

Message #162 received at 448639@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Tollef Fog Heen <tfheen@err.no>
Cc: 448639@bugs.debian.org, clint@ubuntu.com
Subject: Re: Bug#448639: Taking this to the CTTE?
Date: Mon, 30 Aug 2010 22:45:31 +0200
On 30/08/10 at 19:59 +0200, Tollef Fog Heen wrote:
> ]] Lucas Nussbaum 
> | On 28/08/10 at 21:31 +0200, Tollef Fog Heen wrote:
> | > Hi Daigo,
> | > 
> | > using /var/lib/gems is really quite annoying, and I have meant to write
> | > something along the lines of what Clint Byrum wrote a few messages ago.
> | > Sure, using /usr/local isn't ideal, but that's a choice that's up to the
> | > local system administrator; what you're effectively doing is just
> | > forcing people to jump through a hoop and having to add
> | > /var/lib/gems/bin to the default path, which is really quite silly.  The
> | > lack of consistency with what CPAN does is also annoying as we're making
> | > a distribution, not just packaging a bunch of software.
> | > 
> | > So, please, please change this.  If you don't want to change this, I'll
> | > take this to the CTTE so they can rule on this.
> | 
> | While I support the idea of using /usr/local (I even submitted this bug
> | back in 2007), I find it incredible that you threaten to take this to
> | the TC.
> 
> Threaten?  It's the place to take technical arguments that can't be
> resolved by discussion, and this has been a long-standing argument with
> little movement on either side.

Because nobody saw it as something that needed to be solved urgently?

> | There has been basically no activity on this bug between december 2007
> | and now. On August 26th, a Canonical employee restarts that discussion,
> | and two days later, another Canonical employee threatens to take it to
> | the TC?  Come on! Can't we have at least one week of peaceful discussion
> | before you light up the flames?
> 
> I left Canonical years ago, and I don't see why somebody's employment
> would be relevant at all.  I'm, as you can see, writing from my personal
> email address.

OK, I was mistaken on that. Still, I don't think that you should jump in
a thread without really having made any effort to be convincing
yourself, and threaten to appeal the TC. If someone should make that
move, it should be me (as the original bug reporter), or Clint, since he
provided a good rationale and "reopened" the issue. But I hope that none
of us will make that move before we have left that discussion last for
at least a couple weeks.

Lucas




Information forwarded to debian-bugs-dist@lists.debian.org:
Bug#448639; Package libgems-ruby. (Tue, 31 Aug 2010 07:39:35 GMT) Full text and rfc822 format available.

Acknowledgement sent to Daigo Moriwaki <daigo@debian.org>:
Extra info received and forwarded to list. (Tue, 31 Aug 2010 07:39:35 GMT) Full text and rfc822 format available.

Message #167 received at 448639@bugs.debian.org (full text, mbox):

From: Daigo Moriwaki <daigo@debian.org>
To: Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Subject: Re: Bug#448639: /usr/local
Date: Tue, 31 Aug 2010 12:55:16 +0900
Thank you all for the invaluable comments.

We, the Debian Ruby packagers, have decided to make a change on this issue.

As of Ruby 1.9.2, we are merging the rubygems1.9.1 package into the new
ruby1.9.1 (1.9.2.0-1) package since the upstream seems to have integrated
Rubygems with the core more tightly[1]. You will no longer install rubygems1.9.1
as a separate package.

The ruby1.8 package is another story. We will not make significant changes on
ruby1.8 since ruby1.9.1 is (hopefully) getting into the main stream and we'd
like to make more efforts on ruby1.9.1

Anyway, is it correct for me to say that the following locations are our consensus?

default_dir: /usr/local/lib/ruby/gems/1.9.1
default_bindir: /usr/local/bin

A drawback of using /usr/local/bin is that users/administrators have to decide
what executables they want to use. It is up to them to be aware of what they are
installing and manage possible conflicts with other packages or what comes from
other Ruby versions. Fortunately, since gems for ruby1.8 still remains under
/var, ruby1.9.1 and ruby1.8 can co-exist, which, however, may or may not be
doable with future Ruby versions[2].

The advantage of this behavior is that it matches other user-land packaging
systems such as CPAN, pipy, Ruby installed bases on other Operating Systems and
etc. Therefore, users will not be confused about the Debian proprietary locations.


[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=588125
[2] I hope that future Rubygems (upstream) solve this issue. Adding new features
with large patches is beyond Ruby packager's scope.


Regards,
Daigo

-- 
Daigo Moriwaki
daigo at debian dot org





Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Tue, 31 Aug 2010 07:39:37 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gunnar Wolf <gwolf@gwolf.org>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Tue, 31 Aug 2010 07:39:37 GMT) Full text and rfc822 format available.

Message #172 received at 448639@bugs.debian.org (full text, mbox):

From: Gunnar Wolf <gwolf@gwolf.org>
To: Tollef Fog Heen <tfheen@err.no>, 448639@bugs.debian.org
Subject: Re: [DRE-maint] Bug#448639: Taking this to the CTTE?
Date: Mon, 30 Aug 2010 22:40:56 -0500
Tollef Fog Heen dijo [Sat, Aug 28, 2010 at 09:31:03PM +0200]:
> 
> using /var/lib/gems is really quite annoying, and I have meant to write
> something along the lines of what Clint Byrum wrote a few messages ago.
> Sure, using /usr/local isn't ideal, but that's a choice that's up to the
> local system administrator; what you're effectively doing is just
> forcing people to jump through a hoop and having to add
> /var/lib/gems/bin to the default path, which is really quite silly.  The
> lack of consistency with what CPAN does is also annoying as we're making
> a distribution, not just packaging a bunch of software.

FWIW, I agree we should move Gems to /usr/local - It is the place
meant for local-administrator-installed software, and Gems are clearly
not provided by Debian.

> So, please, please change this.  If you don't want to change this, I'll
> take this to the CTTE so they can rule on this.

I'll just join Lucas and ask you not to get over-excited by this. We
are currently in a freeze period, so deep changes are discouraged -
yes, even if we are (subtly IMHO) breaking the FHS. And, in any case,
feel free to push your point, but first on the list, having a
reasonable discussion period.

I would rather see Squeeze ship with Rubygems as they are now. Doing
this change will involve changing Ruby's load path, and that is not
precisely what I'd call a minor change.




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Tue, 31 Aug 2010 14:45:08 GMT) Full text and rfc822 format available.

Acknowledgement sent to Gunnar Wolf <gwolf@gwolf.org>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Tue, 31 Aug 2010 14:45:09 GMT) Full text and rfc822 format available.

Message #177 received at 448639@bugs.debian.org (full text, mbox):

From: Gunnar Wolf <gwolf@gwolf.org>
To: Daigo Moriwaki <daigo@debian.org>, 448639@bugs.debian.org
Cc: Clint Byrum <clint@ubuntu.com>
Subject: Re: [DRE-maint] Bug#448639: /usr/local
Date: Tue, 31 Aug 2010 09:40:26 -0500
Daigo Moriwaki dijo [Tue, Aug 31, 2010 at 12:55:16PM +0900]:
> Thank you all for the invaluable comments.
> 
> We, the Debian Ruby packagers, have decided to make a change on this issue.
> (...)
> Anyway, is it correct for me to say that the following locations are our consensus?
> 
> default_dir: /usr/local/lib/ruby/gems/1.9.1
> default_bindir: /usr/local/bin
> 
> A drawback of using /usr/local/bin is that users/administrators have to decide
> what executables they want to use. It is up to them to be aware of what they are
> installing and manage possible conflicts with other packages or what comes from
> other Ruby versions. Fortunately, since gems for ruby1.8 still remains under
> /var, ruby1.9.1 and ruby1.8 can co-exist, which, however, may or may not be
> doable with future Ruby versions[2].
> 
> The advantage of this behavior is that it matches other user-land packaging
> systems such as CPAN, pipy, Ruby installed bases on other Operating Systems and
> etc. Therefore, users will not be confused about the Debian proprietary locations.

Ummm.. What would you say about setting default_bindir to
/usr/local/bin/ruby/gems/1.9.1 (or something similar), and advising
administrators to symlink whatever binaries they want to be on the
exec path? This leaves /usr/local as the area where all of gems'
"mess" is carried out, while avoiding the installaton of potentially
unchecked code in the default exec path (as others have pointed out in
the last messages)




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Tue, 31 Aug 2010 16:27:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Clint Byrum <clint@ubuntu.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Tue, 31 Aug 2010 16:27:09 GMT) Full text and rfc822 format available.

Message #182 received at 448639@bugs.debian.org (full text, mbox):

From: Clint Byrum <clint@ubuntu.com>
To: Daigo Moriwaki <daigo@debian.org>
Cc: 448639@bugs.debian.org
Subject: Re: Bug#448639: /usr/local
Date: Tue, 31 Aug 2010 09:25:30 -0700
On Aug 30, 2010, at 8:55 PM, Daigo Moriwaki wrote:

> Thank you all for the invaluable comments.
> 
> We, the Debian Ruby packagers, have decided to make a change on this issue.
> 
> As of Ruby 1.9.2, we are merging the rubygems1.9.1 package into the new
> ruby1.9.1 (1.9.2.0-1) package since the upstream seems to have integrated
> Rubygems with the core more tightly[1]. You will no longer install rubygems1.9.1
> as a separate package.
> 
> The ruby1.8 package is another story. We will not make significant changes on
> ruby1.8 since ruby1.9.1 is (hopefully) getting into the main stream and we'd
> like to make more efforts on ruby1.9.1
> 

This seems like an excellent and well thought out solution to this
bug report in general, and also to future maintainability of rubygems.

I actually think its also a nice way of gracefully declining to
change long established behavior in rubygems for 1.8. Users now
have a very clear line they can draw in the sand, and another reason
to move forward with the new version of ruby.


> Anyway, is it correct for me to say that the following locations are our consensus?
> 
> default_dir: /usr/local/lib/ruby/gems/1.9.1
> default_bindir: /usr/local/bin
> 

+1

> 
> [2] I hope that future Rubygems (upstream) solve this issue. Adding new features
> with large patches is beyond Ruby packager's scope.
> 

Agreed on this last point. If it hasn't been requested/reported
upstream, it should be done soon.





Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Thu, 02 Sep 2010 07:39:06 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Thu, 02 Sep 2010 07:39:06 GMT) Full text and rfc822 format available.

Message #187 received at 448639@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Cc: Daigo Moriwaki <daigo@debian.org>
Subject: Re: [DRE-maint] Bug#448639: /usr/local
Date: Thu, 2 Sep 2010 09:26:10 +0200
On 31/08/10 at 09:25 -0700, Clint Byrum wrote:
> 
> On Aug 30, 2010, at 8:55 PM, Daigo Moriwaki wrote:
> 
> > Thank you all for the invaluable comments.
> > 
> > We, the Debian Ruby packagers, have decided to make a change on this issue.
> > 
> > As of Ruby 1.9.2, we are merging the rubygems1.9.1 package into the new
> > ruby1.9.1 (1.9.2.0-1) package since the upstream seems to have integrated
> > Rubygems with the core more tightly[1]. You will no longer install rubygems1.9.1
> > as a separate package.
> > 
> > The ruby1.8 package is another story. We will not make significant changes on
> > ruby1.8 since ruby1.9.1 is (hopefully) getting into the main stream and we'd
> > like to make more efforts on ruby1.9.1
> > 
> 
> This seems like an excellent and well thought out solution to this
> bug report in general, and also to future maintainability of rubygems.
> 
> I actually think its also a nice way of gracefully declining to
> change long established behavior in rubygems for 1.8. Users now
> have a very clear line they can draw in the sand, and another reason
> to move forward with the new version of ruby.

Well, I don't think that the behaviour of rubygems for ruby 1.8 and
1.9.X should be different. It would be great to make the change for both
versions in squeeze.

Lucas




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Thu, 02 Sep 2010 07:39:07 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Thu, 02 Sep 2010 07:39:07 GMT) Full text and rfc822 format available.

Message #192 received at 448639@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Clint Byrum <clint@ubuntu.com>, 448639@bugs.debian.org
Cc: tim@brooklynpenguin.com
Subject: Re: [DRE-maint] Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Date: Thu, 2 Sep 2010 09:23:38 +0200
On 30/08/10 at 08:46 -0700, Clint Byrum wrote:
> rubygems is not an end user tool, it is a development tool.

Note that it is clearly advertised as a end user tool by the upstream
ruby community.

- Lucas




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Thu, 02 Sep 2010 07:39:09 GMT) Full text and rfc822 format available.

Acknowledgement sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Thu, 02 Sep 2010 07:39:09 GMT) Full text and rfc822 format available.

Message #197 received at 448639@bugs.debian.org (full text, mbox):

From: Lucas Nussbaum <lucas@lucas-nussbaum.net>
To: Tim Olsen <tim@brooklynpenguin.com>, 448639@bugs.debian.org
Cc: Adam Jacob <adam@opscode.com>, clint@ubuntu.com
Subject: Re: [DRE-maint] Bug#448639: Debian Bugs information: detailed logs for Bug#448639
Date: Thu, 2 Sep 2010 09:28:57 +0200
On 30/08/10 at 13:58 -0400, Tim Olsen wrote:
> On 08/30/2010 01:38 PM, Adam Jacob wrote:
> > Tim Olsen wrote:
> > 
> >> I am a developer and being able to switch between Ruby 1.8 and Ruby
> >> 1.9.1 gems is important for me.  For example, I use Rubygems-installed
> >> rake to run my automated tests.  All I have to do to see if my tests
> >> work on a different version of Ruby is to update my PATH.  Making sure
> >> that a Ruby library works for both Ruby 1.8 and 1.9 is an important
> >> activity for a Ruby library developer nowadays.
> >>
> >> One minor point: you do not need to be root to modify /usr/local.  On
> >> default Debian installs (but not in Ubuntu), you only need to be in the
> >> staff group.
> > 
> > While this is indeed convenient for the use case, I would argue it's
> > totally out of whack with the expectations that anyone coming to
> > Debian from the Ruby community expects.  The majority of people
> > installing rubygems are doing so because they are using the gem - not
> > because they are doing a development cycle.  The development use case
> > has many other options (rvm, for one) that solve the problem - the
> > end-user case does not, as only Debian policy can fix it. So, I feel
> > your pain, but there is a greatest good argument here in favor of
> > /usr/local.
> 
> Ok.  I agree with you here now.  I'll just have switch to using rvm or
> the like.
> 
> > 
> >> Besides, I'm not convinced that using /usr/local is itself
> >> FHS-compliant.  (I've sent an email earlier about this but I haven't
> >> seen it go through yet).  If upgrading the rubygems package may modify
> >> /usr/local then that violates the FHS: "It needs to be safe from being
> >> overwritten when the system software is updated."
> > 
> > Upgrading rubygems by itself would not update /usr/local, as it is
> > packaged directly within Debian - so it's entirely within our control
> > as to whether or not it updates anything in /usr/local.  To my
> > knowledge, there has never been a rubygems upgrade that forces an
> > update of installed gems automatically, which would be the only case
> > in which this might be in jeopardy.
> 
> What I was more thinking of was if there was a change in how rubygems
> organizes things under /usr/local.  Lucas proposed storing gems under
> /usr/local/lib/ruby/gems/1.8.  But if rubygems needs to move things
> around upon an upgrade, then that's technically a violation.  Even
> setting up directories under /usr/local upon rubygems installation might
> be considered a violation.  One possibility is to store everything *but*
> executables outside of /usr/local.

I think that the best way to solve that problem is to follow what the
upstream developers are doing. After all, if we decide to diverge, and
somehow get it wrong, we will be blamed (and we know from the past that
the Ruby community is quite good at blaming people). If upstream makes
suboptimal choices, and we follow them, we can transfer the blame to
them :P

Lucas




Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Fri, 03 Sep 2010 13:09:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Scott Kitterman <ubuntu@kitterman.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Fri, 03 Sep 2010 13:09:03 GMT) Full text and rfc822 format available.

Message #202 received at 448639@bugs.debian.org (full text, mbox):

From: Scott Kitterman <ubuntu@kitterman.com>
To: ubuntu-devel@lists.ubuntu.com
Cc: Adam Jacob <adam@opscode.com>, 448639@bugs.debian.org
Subject: Re: +1 for /usr/local
Date: Fri, 3 Sep 2010 09:07:57 -0400
[Message part 1 (text/plain, inline)]
On Saturday, August 28, 2010 02:58:04 pm Adam Jacob wrote:
> This has been one of my longest standing issues with Ruby on Debian.
> 
> As a systems administrator, having libraries appear in /var/lib/gems,
> and binaries in /var/lib/gems/1.8/bin is incredibly confusing.  When I
> install a rubygem on a system, I know I'm stepping outside of the
> bounds of Debian's purview - I'm not using apt or dpkg, and I'm
> venturing into the world of external package management.
> Unfortunately, the choice makes it so I loose on two fronts: my
> expectation is that things will wind up in /usr/local (as that's what
> happens when I use CPAN, pypi, or easy_install), but they don't.
> Secondly, unless the maintainer of the application (rails, chef, etc.)
> knows the current status of rubygems on Debian and warns me up front,
> I have no way of discovering a-priori that the changes to my system
> are in /var/lib/gems.
> 
> As an active member of the ruby community, I constantly have to caveat
> that users on Debian will get a sub-par user experience if they use
> the community standard distribution mechanism.  Most often, our advice
> is simply to install the upstream rubygems package from source on
> every Debian system - so that the behavior they experience at least be
> in line with every piece of documentation generated by the ruby
> community.  Unfortunately, this has serious drawbacks - Debian policy
> exists for a reason, and it makes the user experience better.  In this
> case, it makes it significantly worse.  The reputation within the
> community is widely that rubygems on Debian is "broken".
> 
> As a developer of a popular application built with ruby (Chef,) we
> actively maintain and support packages built specifically for Debian.
> I think it's clear to everyone that this should be the preferred path
> for installation on a Debian machine - it ensures compliance with the
> policy, and a smooth and predictable user experience.  In this case
> we're talking about what happens when an administrator explicitly
> decides to take another route - just like when they use CPAN or pypi.
> The reasonable thing to do here is to give them the experience that
> they expect, while still keeping the base system clean for the future
> - and to me, that means /usr/local.
> 
> The comments raised about the possibility of rubygems that install
> binaries that replicate common system utilities is true of any outside
> package management system, or any random tarball installed on the
> system.  We don't alter CPAN, or tar.  Additionally, many rubygems no
> longer even ship with setup.rb, and even fewer will as we move to 1.9,
> where rubygems is a standard part of ruby.
> 
> Please make the defaults be /usr/local.  At the very least, make the
> Gem binary path be /usr/locall/bin.
> 
> Adam

The comparison (at least for Python, I'm not familiar with the others) isn't 
really correct (for Debian/Ubuntu, I don't have other systems to check this 
on).  If I'm using the standard upstream packaging tool (distutils) it 
installs in /usr/local, but in a Python specific directory so the exact concern 
people have expressed about Gems is avoided.

Scott K
[signature.asc (application/pgp-signature, inline)]

Information forwarded to debian-bugs-dist@lists.debian.org, Daigo Moriwaki <daigo@debian.org>:
Bug#448639; Package libgems-ruby. (Fri, 03 Sep 2010 14:18:03 GMT) Full text and rfc822 format available.

Acknowledgement sent to Aigars Mahinovs <aigarius@gmail.com>:
Extra info received and forwarded to list. Copy sent to Daigo Moriwaki <daigo@debian.org>. (Fri, 03 Sep 2010 14:18:03 GMT) Full text and rfc822 format available.

Message #207 received at 448639@bugs.debian.org (full text, mbox):

From: Aigars Mahinovs <aigarius@gmail.com>
To: Scott Kitterman <ubuntu@kitterman.com>
Cc: 448639@bugs.debian.org
Subject: Re: +1 for /usr/local
Date: Fri, 3 Sep 2010 17:15:16 +0300
On 3 September 2010 16:07, Scott Kitterman <ubuntu@kitterman.com> wrote:
>> Please make the defaults be /usr/local.  At the very least, make the
>> Gem binary path be /usr/locall/bin.
>>
>> Adam
>
> The comparison (at least for Python, I'm not familiar with the others) isn't
> really correct (for Debian/Ubuntu, I don't have other systems to check this
> on).  If I'm using the standard upstream packaging tool (distutils) it
> installs in /usr/local, but in a Python specific directory so the exact concern
> people have expressed about Gems is avoided.
>

Actually easy_install also installs run scripts from Python eggs (if
there are any) and those get installed into /usr/local/bin by default.

-- 
Best regards,
    Aigars Mahinovs        mailto:aigarius@debian.org
  #--------------------------------------------------------------#
 | .''`.    Debian GNU/Linux (http://www.debian.org)            |
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv)     |
 | `. `'    Linux Administration and Free Software Consulting   |
 |   `-                                 (http://www.aiteki.com) |
 #--------------------------------------------------------------#




Reply sent to Daigo Moriwaki <daigo@debian.org>:
You have taken responsibility. (Fri, 29 Apr 2011 16:21:05 GMT) Full text and rfc822 format available.

Notification sent to Lucas Nussbaum <lucas@lucas-nussbaum.net>:
Bug acknowledged by developer. (Fri, 29 Apr 2011 16:21:05 GMT) Full text and rfc822 format available.

Message #212 received at 448639-close@bugs.debian.org (full text, mbox):

From: Daigo Moriwaki <daigo@debian.org>
To: 448639-close@bugs.debian.org
Subject: Bug#448639: fixed in rubygems 1.7.2-1
Date: Fri, 29 Apr 2011 16:19:31 +0000
Source: rubygems
Source-Version: 1.7.2-1

We believe that the bug you reported is fixed in the latest version of
rubygems, which is due to be installed in the Debian FTP archive:

rubygems-doc_1.7.2-1_all.deb
  to main/r/rubygems/rubygems-doc_1.7.2-1_all.deb
rubygems1.8_1.7.2-1_all.deb
  to main/r/rubygems/rubygems1.8_1.7.2-1_all.deb
rubygems_1.7.2-1.debian.tar.gz
  to main/r/rubygems/rubygems_1.7.2-1.debian.tar.gz
rubygems_1.7.2-1.dsc
  to main/r/rubygems/rubygems_1.7.2-1.dsc
rubygems_1.7.2-1_all.deb
  to main/r/rubygems/rubygems_1.7.2-1_all.deb
rubygems_1.7.2.orig.tar.gz
  to main/r/rubygems/rubygems_1.7.2.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 448639@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Daigo Moriwaki <daigo@debian.org> (supplier of updated rubygems package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Fri, 29 Apr 2011 19:07:08 +0900
Source: rubygems
Binary: rubygems rubygems1.8 rubygems-doc
Architecture: source all
Version: 1.7.2-1
Distribution: unstable
Urgency: low
Maintainer: Daigo Moriwaki <daigo@debian.org>
Changed-By: Daigo Moriwaki <daigo@debian.org>
Description: 
 rubygems   - package management framework for Ruby libraries/applications
 rubygems-doc - Transitional package for rubygems
 rubygems1.8 - Transitional package for rubygems
Closes: 403407 448639
Changes: 
 rubygems (1.7.2-1) unstable; urgency=low
 .
   [ Lucas Nussbaum ]
   * New upstream release.
   * Switch to gem2deb-based packaging. Rename source and binary packages.
   * Drop 50_add_missing_require_yaml.diff: fixed upstream.
   * Change 01_default_gem_path.diff:
     + executables are now installed to /usr/local/bin.
     + but the other files created by rubygems stay in /var/lib/gems/1.8.
     Several commenters in #448639 and #403407 argued in favor of the switch to
     /usr/local/bin. Those two bugs can therefore be closed. However, the issue
     is not completely solved, as rubygems still installs files in /var/lib/gems.
     Nobody in the bug logs explained why that was an issue. If you care about
     it, please open a new bug. Closes: #448639, #403407
   * Add disable-failing-tests.diff: disable tests that are failing due to
     Debian-specific changes to rubygems.
 .
   [ Daigo Moriwaki ]
   * Switched the build framework from cdbs to dh. (thanks to Lucas)
Checksums-Sha1: 
 b4f5a7a4f44aab1b0d89a1293052a0ebd00893b6 1410 rubygems_1.7.2-1.dsc
 d878ae52f40eb71e59708afc57303172f0327fad 245606 rubygems_1.7.2.orig.tar.gz
 39fb260e11da629bc4463be0e763806c97279ff3 24086 rubygems_1.7.2-1.debian.tar.gz
 f20eb7b0aab2691817d0dd70c354778873b00b15 446258 rubygems_1.7.2-1_all.deb
 107d594cee8f7a707b499d3bc09fedbd5154de0b 24734 rubygems1.8_1.7.2-1_all.deb
 1d65743cd2aca1c2948bd5d1e1c29f3a251bbf2d 24738 rubygems-doc_1.7.2-1_all.deb
Checksums-Sha256: 
 0db30e9d6cc6fb7b5c5ee0b5b1f15da28886c2d1a1fcc68c776623431d1a63a1 1410 rubygems_1.7.2-1.dsc
 28c6969d48e2ec0d9df6ccd7c73d46d9b0c115ca6acb34f091b39a3e9049692c 245606 rubygems_1.7.2.orig.tar.gz
 3c8106d4104646e12c904846100e5bc03f57a0df4a68a50925d96ba47d28e93a 24086 rubygems_1.7.2-1.debian.tar.gz
 8ed057610ecf416d7ce25d80260d83b8e815749a7a72b498d7c8cb2bffb68498 446258 rubygems_1.7.2-1_all.deb
 bf31dcd2d22e9c84329a296899c6fdade707ced0800171b97957a7dd8f25b18b 24734 rubygems1.8_1.7.2-1_all.deb
 cb587fdaf6b7e415c12859736534a5107d584dc12d95a4a2fbe35093ba21b532 24738 rubygems-doc_1.7.2-1_all.deb
Files: 
 bcfd65ffc62acf51b41dd3193c19c2c1 1410 ruby optional rubygems_1.7.2-1.dsc
 8d67d0bc44b0317dc37e200dcf6627ea 245606 ruby optional rubygems_1.7.2.orig.tar.gz
 1464f1f2988b8d0a222a70c140c93497 24086 ruby optional rubygems_1.7.2-1.debian.tar.gz
 b84c9c97299baedec1d792ae30cd51c5 446258 ruby optional rubygems_1.7.2-1_all.deb
 4afdcc8ed28ee6d959defa36b396c33a 24734 oldlibs optional rubygems1.8_1.7.2-1_all.deb
 6b0945175c5daae9c4fe2b243dff8912 24738 oldlibs optional rubygems-doc_1.7.2-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iEYEARECAAYFAk264PEACgkQNcPj+ukc0lAzqACgvGqAq8geb9+FAGbVK+4Gnlci
aWYAoJgBmOXuzIKgIQq85DEs8aO7ZmMb
=YLOY
-----END PGP SIGNATURE-----





Bug archived. Request was from Debbugs Internal Request <owner@bugs.debian.org> to internal_control@bugs.debian.org. (Sat, 28 May 2011 07:36:19 GMT) Full text and rfc822 format available.

Send a report that this bug log contains spam.


Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Sun Apr 20 23:59:43 2014; Machine Name: beach.debian.org

Debian Bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.