rpa-base, ruby-gems and native package installers

[Ruben]

Hello,

I was wondering about the relation between rpa-base and/or ruby-gems
and native package installers on linux like APT on Debian and Portage
on Gentoo.

Is it the intention that Debian/Portage build their own version of
packages like ruby-opengl, ruby-gtk2,... or that they build a kind of
'dumb' package which relies on rpa-base/ruby-gems to install those
packages ? Or that those systems live next to each other ? Or is it
mainly meant to use those tools as a regular user with the purpose of
having your own versions of the ruby libraries you want without
needing superuser access ?

Just wondering..

Ruben

 

[David Ross]

Hello,

I was wondering about the relation between rpa-base
and/or ruby-gems
and native package installers on linux like APT on
Debian and Portage
on Gentoo.

Is it the intention that Debian/Portage build their
own version of
packages like ruby-opengl, ruby-gtk2,... or that
they build a kind of
'dumb' package which relies on rpa-base/ruby-gems to
install those
packages ? Or that those systems live next to each
other ? Or is it
mainly meant to use those tools as a regular user
with the purpose of
having your own versions of the ruby libraries you
want without
needing superuser access ?

Just wondering..

Ruben

The system package manager and rpa base can live next
to each other. Rpa-base won't install if the files are
already there, but the system package manger might
even though the file exists. Ex. FreeBSD ports, it
doesnt check wether files exist before installing, a
package manager design flaw. :/ I live with it though
System package managers handle thier own ports.
Sometime in the future Rpa-base will be able to
integrate with the system package manager. Hopefully
the OS distributors like FreeBSD, Debian, and Gentoo
will accept over 100 port entries to be added and get
rid of the existing ruby ports since they usually are
not updated.


----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------




__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - Send 10MB messages!
http://promotions.yahoo.com/new_mail

 

[Mauricio Fernández]

Hello,

I was wondering about the relation between rpa-base and/or ruby-gems
and native package installers on linux like APT on Debian and Portage
on Gentoo.

I wanted integration with the system package/port manager even before
the very first discussions about RPA took place in #ruby-lang (IRC),
and long before I began to work on rpa-base.

Is it the intention that Debian/Portage build their own version of
packages like ruby-opengl, ruby-gtk2,... or that they build a kind of
'dumb' package which relies on rpa-base/ruby-gems to install those
packages ?

I think the former is better. The idea is making RPA's packages
(including associated metadata, etc) good enough to allow them to be
used as the basis for other packages. In other words, taking Debian as
an example, it would be possible to generate a debianized source tree
from a RPA port. Now, direct .rps/.rpa => .deb conversion IS possible, but
it is better to respect Debian/FreeBSD/Gentoo/etc 's normal procedures.

rpa-base is essentially repackager-friendly (but it will soon become
better), and a number of parameters (installation paths, handling
of rdoc/ri documentation) can be adapted to comply with the desired
filesystem/etc standards.

Or that those systems live next to each other ? Or is it

This is the current situation. rpa-base tries to play nice with other
port/pkg managers and will not overwrite any file unless you indicate
it's OK.

mainly meant to use those tools as a regular user with the purpose of
having your own versions of the ruby libraries you want without
needing superuser access ?

You can also use rpa-base that way: just set the $prefix to some directory
you own when installing rpa-base for the first time. On my system, I
have 3 rpa-base installed: one in $HOME/usr (where I have the latest
stable snapshot of Ruby too), one in $HOME/ruby1.9 (1.9 CVS) and the
system-wide one in /usr/local.

 

[Ruben]

At Wed, 18 Aug 2004 18:13:01 +0900,

The system package manager and rpa base can live next
to each other. Rpa-base won't install if the files are
already there, but the system package manger might
even though the file exists. Ex. FreeBSD ports, it
doesnt check wether files exist before installing, a
package manager design flaw. :/ I live with it though
System package managers handle thier own ports.
Sometime in the future Rpa-base will be able to
integrate with the system package manager. Hopefully
the OS distributors like FreeBSD, Debian, and Gentoo
will accept over 100 port entries to be added and get
rid of the existing ruby ports since they usually are
not updated.

I am rather reluctant about installing files that the native package
manager doesn't know about (unless they can be installed in a seperate
place). But it'd be nice if it can be integrated somehow with the
system package manager.

Ruben

 

[Ruben]

At Wed, 18 Aug 2004 19:59:20 +0900,

I think the former is better. The idea is making RPA's packages
(including associated metadata, etc) good enough to allow them to be
used as the basis for other packages. In other words, taking Debian as
an example, it would be possible to generate a debianized source tree
from a RPA port. Now, direct .rps/.rpa => .deb conversion IS possible, but
it is better to respect Debian/FreeBSD/Gentoo/etc 's normal procedures.

rpa-base is essentially repackager-friendly (but it will soon become
better), and a number of parameters (installation paths, handling
of rdoc/ri documentation) can be adapted to comply with the desired
filesystem/etc standards.

This sounds very good I hope you'll reach this goal, this should
result in less work for Debian/FreeBSD/Gentoo/etc package maintainers,
and hopefully more ruby-related and more up-to-date packages on those
systems.

This is the current situation. rpa-base tries to play nice with other
port/pkg managers and will not overwrite any file unless you indicate
it's OK.

Ok, but for me personally, this is still not a good solution, because
i want to keep 'native' package files and rpa-installed package files
separated.. but...

You can also use rpa-base that way: just set the $prefix to some directory
you own when installing rpa-base for the first time. On my system, I
have 3 rpa-base installed: one in $HOME/usr (where I have the latest
stable snapshot of Ruby too), one in $HOME/ruby1.9 (1.9 CVS) and the
system-wide one in /usr/local.

this seems perfect for now, this way i can install things with
rpa-base without messing up my system.

Thanks for the explanation and for the work and time you put in rpa.

Ruben

 

[David Ross]

Right, thats what it is planned, both rpa *and* the
system package mananger can deal with it so you could
deisntall/install either way. The rpa-base would still
be needed. Rpa-base would be more of an interface when
using it combined. I am sure you could use a
generation program and generate lets just say..
FreeBSD ports to send. That would work also, but it
would be a pain to make sure that they are working. If
you made rpa a req' to install software it would be
much easier since it handles all the ruby
install/compile stuff .

At Wed, 18 Aug 2004 18:13:01 +0900,


I am rather reluctant about installing files that
the native package
manager doesn't know about (unless they can be
installed in a seperate
place). But it'd be nice if it can be integrated
somehow with the
system package manager.

Ruben

----------------------------------------
-- Name: David Ross
-- Phone: 865.539.3798
-- Email: drossruby [at] yahoo [dot] com
----------------------------------------



__________________________________
Do you Yahoo!?
Yahoo! Mail - Helps protect you from nasty viruses.
http://promotions.yahoo.com/new_mail