* Marcus Rueckert <darix(a)opensu.se> [Mar 31. 2011 18:10]:
On 2011-03-31 17:13:46 +0200, Klaus Kaempf wrote:
Uh, I'd consider this an ugly hack.
all other options would be more ugly and have more pain in the long run.
e.g. for distro releases we obsolete old shared library packages with a
list in the installer. that isnt even an option for us in a project as
the goal for dlre is simple: have one working set of all gems we want to
provide and if one version of "foo" can give us that fine.
I fear, this is an impossible goal. It might get a bit more feasible
if we split dlre:rails2 and dlre:rails3, maintaining the respective
latest rails versions there.
where we know we will need more than one version. we will have to go the
hard way with the suffixes on the package name.
If the buildservice supports this in a semi-automatic way, I'd be
willing to help.
If an user needs gems in
more versions he still has the option to install them manually via gem.
Yeah, thats probably how I will set up my future Rails projects. The
equation of GEM+RPM+OBS is just too hard to solve.
If we want to switch to "provide packages for all gems in all version",
we need to discuss how that will be buildable in the long run without
DOS-ing the OBS. even atm ... updating rubygems and then having the
whole project rebuild has noticable effects on the obs. (coolo even
disabled the project at one point so he can get a factory build done. ;) )
Sounds more like an urgent need to prioritize projects in the build
Klaus (who updated rubygems 2 times during the last 24 hrs ;-) )
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
To unsubscribe, e-mail: opensuse-ruby+unsubscribe(a)opensuse.org
For additional commands, e-mail: opensuse-ruby+help(a)opensuse.org