Comment 48 for bug 145267

Hi,

On Thu, Aug 14, 2008 at 05:48:34AM -0000, Lucas Nussbaum wrote:
> Some comments:
> - debian/operating_system.rb is not properly licensed, and not mentioned in debian/copyright.

debian/operating_system.rb has the following statement:

# Licensed unded the GPL. See /usr/share/common-licenses/GPL

Isn't that enough ? Adding a mention to the debian/copyright file would
be advisable though.

> - I'm still not convinced by your update-alternatives hack. This should *really* go upstream, so it's fixed for every distro, not just Ubuntu.

Agreed. The gem system has currently shortcomings. The
update-alternatives proposal is one way to address the issue. Upstream
seems cooperative on that point as it provided the necessary hooks to
implement such a system. So upstream is aware of the problem. They may
work on solving it and it can take some time.

On the other hand this proposal is one step toward fixing the issue, and
it works now. Once upstream comes up with a good solution, we can
revisit the usage of update-alternatives to manage gems binaries in
/usr/local/bin.

> - you base your version on a git snapshot, with a >5kloc diff compared to the current version in debian unstable. Is that really reasonable, since we are far in the Ubuntu release cycle AFAIK?

IMO this is perfectly acceptable as we're not past FeatureFreeze. That
means new upstream version can still be uploaded to the archive.
Moreover this is code that is coming from upstream, so it will be
available in the next upstream release.

> - have you talked to Daigo Moriwaki about those deep changes to his Debian package? If not, when do you plan to?

Talking to Daigo Moriwaki would be helpful. However considering the
current freeze for Lenny I doubt that this patch will be accepted in
Debian before Ubuntu enters FeatureFreeze.

> - What's the Ubuntu policy about hosting VCS branches for packages? Shouldn't you use bzr on launchpad instead?

There isn't a real policy. People have the choice of VCS and where to
host their code repository. It's true that most of the Ubuntu Developers
will use bzr, but some packages are maintained in git for example
(postfix for example).

>
> Most importantly, your motivations sound unclear to me:
> > > No, it's a patch that makes rubygems work better on systems with
> > > update-alternatives, while you should aim at a global solution instead.
> >
> > No I aim for the simplest solution that will solve the most pain in
> > the shortest possible time. Others can then generalise that if they
> > want. My time is paid for don't forget.
> >
> > From an Ubuntu point of view a superior package is good, because it
> > gives people a reason why they should use Ubuntu and switch to the
> > package rather than continue to mess around with the source package as
> > they do now.
> >
> > Certainly I'm not going to get my 200 odd customers to move away from
> > source installation without a nice fat carrot to offer them.
>
> If I understand it correctly, you want to give Ubuntu a competitive
> advantage by not working with upstream to address this problem globally.
> That doesn't sound right.
>

We're trying to improve the usage of gems so that the end user has a
good experience using it on Ubuntu. This work involves upstream (they
provided the necessary hooks) and also some integration work by the
Ubuntu team so that cooperation with dpkg works well. IMO upstream won't
be able to resolve all of the issue as there will always be some distro
specific details (location of paths, support for multiple versions).

--
Mathias Gug
Ubuntu Developer http://www.ubuntu.com