[Rubygems-developers] Customising Rubygems for Debian/Ubuntu.
Neil Wilson
Debian/Ubuntu that will allow 'gem' and 'apt' to work together
interchangeably on a Debian/Ubuntu platform *and* be compatible with
Debian's filesystem policies.
To do that I need to use the 'alternatives' system so that the OS
knows which is the current version of an application. Essentially gem
will install an 'app1.8' or 'app1.9' link to the relevant binary and
the 'alternatives' system will create 'app' in the system path.
What I need to do is call the command 'update-alternatives' on install
and deinstall, which corresponds to the 'postinst' and 'prerm' scripts
you get under 'apt' packaging.
However I can't see any prebuilt hooks (empty methods would do) in the
code that I can override with the new 'operating_system.rb' file. Any
chance of putting in simple hook methods in the relevant place?
What I could do with is
- 'preinst' and 'postinst' called at the relevant places in install
- 'prerm' and 'postrm' called at relevant places in uninstall
- 'update-system' called when gem is doing an 'update --system' so
that I can redirect that to use 'apt' instead'.
Of course any other suggestions on how to get this done gratefully received.
--
Neil Wilson
_______________________________________________
Rubygems-developers mailing list
Rubygems-...@rubyforge.org
http://rubyforge.org/mailman/listinfo/rubygems-developers
Eric Hodel
> To do that I need to use the 'alternatives' system so that the OS
> knows which is the current version of an application. Essentially gem
> will install an 'app1.8' or 'app1.9' link to the relevant binary and
> the 'alternatives' system will create 'app' in the system path.
Is this for `gem` itself or for a gem-installed executable?
Eric Hodel
> On Jun 25, 2008, at 22:42 PM, Neil Wilson wrote:
>> To do that I need to use the 'alternatives' system so that the OS
>> knows which is the current version of an application. Essentially gem
>> will install an 'app1.8' or 'app1.9' link to the relevant binary and
>> the 'alternatives' system will create 'app' in the system path.
>
> Is this for `gem` itself or for a gem-installed executable?
... or a apt-installed gem's executable?
Neil Wilson
> Is this for `gem` itself or for a gem-installed executable?
It is for the gem installed exectuable. Gem would install, say,
'mongrel_rails1.8' and then call 'update-alternatives' so that the
alternatives system creates the necessary symlinks allowing the user
to run 'mongrel_rails'.
Rubygems is installed by 'apt' and 'apt' takes care running 'update
alternatives' for the 'gem' command. Hence why I want 'update
--system' to divert to running 'apt-get'.
The general idea is that when the user switches versions of ruby -
between 1.8, 1.9, rubinus or jruby the alternatives system causes the
symlinks to switch and follow the 'current' flavour of Ruby.
That and finally getting installed gem binaries on the PATH in
Debian/Ubuntu without violating their file systems policy...
In theory then apt packages generated from gems and gems installed
directly will co-operate with each other. The nirvana of automatic
apt-packages generated directly from gems should then by a SMOP (he
says idealistically :-)
--
Neil Wilson
Eric Hodel
> 2008/6/27 Eric Hodel <drb...@segment7.net>:
>> Is this for `gem` itself or for a gem-installed executable?
>
> It is for the gem installed exectuable. Gem would install, say,
> 'mongrel_rails1.8' and then call 'update-alternatives' so that the
> alternatives system creates the necessary symlinks allowing the user
> to run 'mongrel_rails'.
Ok.
In r1829 I have added:
Gem.pre_install
Gem.post_install
Gem.pre_uninstall
Gem.post_uninstall
each takes a block that is saved then called with the Gem::Installer/
Gem::Uninstaller instance for the gem being installed/uninstalled at
the appropriate time. Multiple pre/post install hooks are supported.
Gem.post_install do |installer|
puts "!!! #{installer.spec.full_name} INSTALLED !!!"
end
Gem.post_uninstall do |uninstaller|
puts "!!! #{uninstaller.spec.full_name} UNINSTALLED !!!"
end
Neil Wilson
> Ok.
>
> In r1829 I have added:
>
> Gem.pre_install
> Gem.post_install
> Gem.pre_uninstall
> Gem.post_uninstall
>
> each takes a block that is saved then called with the
> installed/uninstalled at the appropriate time. Multiple pre/post install
> hooks are supported.
>
> Gem.post_install do |installer|
> puts "!!! #{installer.spec.full_name} INSTALLED !!!"
> end
>
> Gem.post_uninstall do |uninstaller|
> puts "!!! #{uninstaller.spec.full_name} UNINSTALLED !!!"
> end
Thanks for that Eric. I'll have a play.
Do I define these in the 'operating_system.rb' file, or elsewhere? And
I presume they act on all gems installed/uninstalled on a system (ie
the hook isn't specific to a gem and stored in the gem package
somewhere).
--
Neil Wilson
Eric Hodel
> 2008/6/30 Eric Hodel <drb...@segment7.net>:
>> Ok.
>>
>> In r1829 I have added:
>>
>> Gem.pre_install
>> Gem.post_install
>> Gem.pre_uninstall
>> Gem.post_uninstall
>
>
> Do I define these in the 'operating_system.rb' file, or elsewhere? And
> I presume they act on all gems installed/uninstalled on a system (ie
> the hook isn't specific to a gem and stored in the gem package
> somewhere).
You would define what you need in operating_system.rb.
These hooks are only available for packagers and implementors, gems
themselves cannot define any hooks.
One note I forgot to make was that they are called regardless of
installation path, so if I run `gem install some_gem -i ~/tmp/gems`
you may not want to update alternatives. (Rubinius will take
advantage of these to compile all the .rb files, for example).
Since I just remembered this, I added #bin_dir and #gem_home to
Installer and Uninstaller so you can determine whether or not to run
update alternatives.