Package maintainer Jonas Smedegaard requested that I file my comments on
this bug/issue at this address.
Summary: As I understand the situation, Debian distributions include
Ruby as well as some well known and lesser known software libraries for
Ruby, independently packaged as Debian packages. Also, it is fairly
common in Ruby practice and documentation for Ruby users and developers
to install these same packages from remote repositories using the Ruby
command called 'gem'. What I understand from Jonas is that current
(so far as I know undocumented) Debian policy in this area is that it is
an unsupported and potentially disabling error for a Debian user to
install a package through the "native" Ruby gem mechanism - i.e. to
execute "sudo gem install <package name>" when that same (or different
version of that) package has independently being installed as a Debian
package.
I unwittingly experienced this issue when I installed the Debian package
called compass-susy-plugin, and then, later, following some basic
tutorials for the Susy library that were available on the web, executed
"sudo gem install susy". For me, the result was that the Ruby library
compass (for which Susy is an add-on) became silently broken - when I
attempted to run compass to work with Susy, it gave unhelpful error
messages indicating bad syntax constructions in the materials it was
parsing - the same materials that were introduced in the basic tutorials
for Susy. In fact, my problem was that there were software conflicts
between the Debian packages versions of compass and Susy and the ones
installed through Ruby gem - possibly different versions and definitely
different locations (gem installed under /usr/local). I fixed my
problem by purging the Debian packages ruby-sass, ruby-compass, and
compass-susy-plugin and installing the default versions through Ruby
gem. However, being a newbie to Ruby, compass, and advanced CSS3
crafting (which is what Susy does), it took me several frustrating hours
to realize that my problem was actually with a broken software
installation and was not related to how I was modifying the example code
in the tutorials or how I was using compass.
As far as my own work goes, it was a satisfactory solution for me to
just not use the Debian versions of Ruby packages, but I am motivated to
comment on this situation by a desire to help other users who might
inadvertently experience parallel problems with Ruby packages and to
help the Debian community improve its overall distribution.
As I see things, it is a very bad plan/design to have a system with the
property that using Ruby in a regular way and/or following basic
tutorials for Ruby library usage that are available on the web causes
the relevant part of the Debian system to silently break - it my case,
for instance, the only visible sign that there was something wrong was
transmitted as error messages about bad syntax in user/library bits of
code for the sass/compass CSS meta-programming language - messages which
were wrong and had nothing to do with the actual problem. As a newbie
user of these libraries/packages, this was very frustrating, but it
seems to me that even an expert user could easily run "sudo gem install
<package>" for some package he didn't realize or forgot had already been
installed through the Debian system - especially if he wanted a newer
version of the package at some point well after his Debian system was
first installed with some forgotten old version. Moreover, since gem
can silently install Ruby dependencies, it may be possible to install a
Ruby package that conflicts with an installed Debian version even by
installing some other package directly through gem and having an updated
version of the conflicting package pulled in as Ruby dependency.
It may be that one motivation for Debian packaging of Ruby libraries is
to insure better security of the packages. In this case though, the
same comments above about creating broken libraries also apply to the
possibility of accidentally creating a less secure system.
The following possibilities seem better to me than the current Debian
approach in this area:
Possibility 1) Don't create Debian packages for libraries available
through gem.
Possibility 2) Patch Ruby gem to warn about or disable installation of
conflicting libraries (the user could be told how to purge the Debian
versions in the warning message as one possible option).
Possibility 3) Debian could maintain it's own version of Ruby
repositories and insure that high grade security options are in place by
default for gem usage.
It might be interesting to think about some of these issues in the
broader context of Debian approaches to other non-Ruby software systems
that have there own package repository system - e.g. Java maven,
Eclipse, Perl, etc.
Thank you for you attention.
-= Josh Stern
According to my experience, and the feedback I have rec
On 04/10/2013 05:03 PM, Josh Stern wrote:
I don't think it is wrong not to "support" mixing, but I think it is
wrong to have a package where as soon as one tries to follow any of
the available elementary tutorials one ends up with a broken system.
For the newbie, there is no way to know that they are doing something
"unsupported". They just get something which mysteriously fails to
work and gives unhelpful error messages. It seems like in this case
the expert would not have much use for the package - they already use
gem for this - so I'm not sure who it is helping (and I see who it is
hurting) in this unsupported state.
On 04/10/2013 04:41 PM, Jonas Smedegaard wrote:
Quoting Josh Stern (2013-04-10 21:20:56)
Somewhere in the course of doing that, I executed the command:
sudo gem install susy
I appreciate your interest in Compass and Susy, and in your reporting
bugs you experience with their packaging for Debian.
However, mixing Debian with non-Debian packaging (which gem is) is not
supported, and I therefore close this as a non-bug.
Sorry for the time you have wasted struggling with this :-(
This - based on http://compass-style.org/help/ - should work:
compass create my_project --using susy
Regards,
- Jonas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
