On 2011-03-30 16:21:42 +0200, Pavol Rusnak wrote:

As a part of our Boosters' sprint we try to get more packages to Factory. I checked d:l:r:e and only 44 out of 662 rubygems maintained there are also submitted to Factory. I'd like to start a discussion if we want to create out-of-the-box experience for Ruby developers or we'd rather force them to add d:l:r:e repo to their system. Both approaches have their advantages and disadvantages and I'd like to hear your opinions ...

we dont even manage to keep all the packages in the dlre up2date. do you really think we will have the man power to maintain 600 in a distro under the current rules? (and no i dont object the rules. they are there for a reason.) that said ... i dont think pushing every of those packages into the distro is needed. especially as dlre is a relatively confined area and not many overlappings with other projects. darix p.s.: just to make sure .... who ever pushes a package into the distro is the maintainer in the distro. -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

Pavol Rusnak write:

On 30/03/11 16:27, Marcus Rueckert wrote:

...

we dont even manage to keep all the packages in the dlre up2date. do you really think we will have the man power to maintain 600 in a distro under the current rules? (and no i dont object the rules. they are there for a reason.)

No we don't and we won't have the power if we keep being exclusive instead of inclusive. That's what we're trying to change for the last few months or maybe years. I am not proposing anything concrete, I am just asking for opinions.

...

that said ... i dont think pushing every of those packages into the distro is needed. especially as dlre is a relatively confined area and not many overlappings with other projects.

Maybe it helps if I rephrase the question: Do we want to have some out-of-the-box experience for Ruby people (with the possibility of outdated packages) or rather none at all?

PS: I'm fine with both options, but I want to make sure we all are on the same page, because I don't think this was discussed previously ...

I think that we should at first decide how should look our ruby ecosystem, because part of out ruby libraries is not packed as rubygems, so all dependencies cannot easy use it without tweaking spec file. Examples is facter or puppet in factory. I think we should at first define how looks ruby library in our distro and what level of support we want provide because many gems contain even trivial mistakes. Pepa -- Josef Reidinger Appliance Toolkit team maintainer of perl-Bootloader and parts of webyast and SLMS author of rubygems - studio_api and net_observer (coauthor) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

On 2011-03-30 17:29:38 +0200, Klaus Kaempf wrote:

* Pavol Rusnak [Mar 30. 2011 16:18]:

...

Hi all!

As a part of our Boosters' sprint we try to get more packages to Factory. I checked d:l:r:e and only 44 out of 662 rubygems maintained there are also submitted to Factory. I'd like to start a discussion if we want to create out-of-the-box experience for Ruby developers or we'd rather force them to add d:l:r:e repo to their system.

Besides the fact that I totally object the 'one big repo' approach of Factory[1], I do not think this is maintainable at all.

I do not object pointing openSUSE users to d:l:r:e but the current project setup is not well suited to this.

I did quite some gem updates in d:l:r:e lately and experienced quite some trouble due to dependencies. Thats not a fault of rubygem but comes from the build service not supporting packages in multiple versions.

I'd like to see d:l:r:e:staging for getting all dependencies right after version updates. Then buildservice needs to offer a way to push d:l:r:e:staging to d:l:r:e in an 'atomic' way.

Still there will be people out there relying on specific versions of gems. And I don't see a way to support them without *a lot* of manual effort (and package renames :-/)

the only real solution to having multiple versions of the same gem installed is the approach with suffixes on package names. imho darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

* Marcus Rueckert [Mar 30. 2011 17:36]:

...

Still there will be people out there relying on specific versions of gems. And I don't see a way to support them without *a lot* of manual effort (and package renames :-/)

the only real solution to having multiple versions of the same gem installed is the approach with suffixes on package names.

Hmm, gem and rpm support multiple installed versions of the same gem/package. So the limitation is the build service. Can we automate suffixes on package names somehow ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

* Marcus Rueckert [Mar 30. 2011 21:21]:

On 2011-03-30 21:08:57 +0200, Klaus Kaempf wrote:

...

Hmm, gem and rpm support multiple installed versions of the same gem/package. So the limitation is the build service.

rpms supports it somehow. how well are all package manager on top of it handle it?

Yeah, thats another question ...

...

Can we automate suffixes on package names somehow ?

no. we dont want that.

Why ? Any reasoning for that ? Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

On Thursday, March 31, 2011 10:11:21 am Duncan Mac-Vicar P. wrote:

rvm provides a much superior experience for ruby developers than d:l:r:e, so I would focus on providing an easy way to get rvm in and configured.

You are right, rvm is really cool. How would you like to see it integrated into SUSE? Cheers Flavio -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

On 2011-03-31 09:23:05 +0200, Klaus Kaempf wrote:

...

...

Can we automate suffixes on package names somehow ?

no. we dont want that.

Why ? Any reasoning for that ?

we dont need it all the time? it makes it almost impossible to get rid of the outdated packages? (no an obsolete for foo-1_1 in the foo-1_2 is *not* the right answer) and we currently use 2 different techniques anyway 1. when we want to have a long term maintenance of 2 parallel branches of a package -> suffixed version. (e.g. rails+rails plugins) 2. for temporary solutions i just provide the old and the new version in the same package. had to do that when rails 3 was out fresh and rails 2 didnt work with rack 1.1. then the rack package had both versions in it as a temporary workaround. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

* Marcus Rueckert [Mar 31. 2011 16:53]:

On 2011-03-31 09:23:05 +0200, Klaus Kaempf wrote:

...

...

...

Can we automate suffixes on package names somehow ?

no. we dont want that.

Why ? Any reasoning for that ?

we dont need it all the time?

Of course not. But when we need it, it should have the lowest possible overhead (for the packager)

it makes it almost impossible to get rid of the outdated packages? (no an obsolete for foo-1_1 in the foo-1_2 is *not* the right answer)

I _do_ want foo-1.1 and foo-1.2 installed in parallel. Thats the whole point. And only I (as the user of the gems) can decide when to clean up old versions. Cleaning up old versions needs tool support anyways, with or without suffixes.

and we currently use 2 different techniques anyway

1. when we want to have a long term maintenance of 2 parallel branches of a package -> suffixed version. (e.g. rails+rails plugins)

Understood. Still missing is an easy way for packagers to provide 'suffixed packages' to the buildservice.

2. for temporary solutions i just provide the old and the new version in the same package. had to do that when rails 3 was out fresh and rails 2 didnt work with rack 1.1.

Uh, I'd consider this an ugly hack. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

* Marcus Rueckert [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 dlre.

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.

for things 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 service. 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@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

* Marcus Rueckert [Mar 31. 2011 20:52]:

On 2011-03-31 20:45:31 +0200, Klaus Kaempf wrote:

...

Klaus (who updated rubygems 2 times during the last 24 hrs ;-) )

except that those hashvalue to big changes are actually a bug in the old ruby package and not rubygems. *sigh*

Yeah, and ruby didn't really care. (http://revision-zero.org/history-of-a-bug) :-/ Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

* Marcus Rueckert [Mar 31. 2011 21:34]:

On 2011-03-31 21:13:48 +0200, Klaus Kaempf wrote:

...

* Marcus Rueckert [Mar 31. 2011 20:52]:

...

On 2011-03-31 20:45:31 +0200, Klaus Kaempf wrote:

...

Klaus (who updated rubygems 2 times during the last 24 hrs ;-) )

except that those hashvalue to big changes are actually a bug in the old ruby package and not rubygems. *sigh*

Yeah, and ruby didn't really care. (http://revision-zero.org/history-of-a-bug)

given it was fixed between p174 and p248 i wouldnt call it "didnt care" so the real solution would be to find the changeset that fixed it between those 2 patchlevels and then apply it to our ruby packages on the older distros. wouldnt you agree?

Fixing rubygems was *way* easier than trying to isolate the correct ruby fix and getting e.g. SLES10 ruby updated. Klaus --- SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org

On 2011-04-05 17:51:33 +0200, Martin Vidner wrote:

I think a valuable enhancement would be to make RVM manage many system rubies, so that we combine the strengths of openSUSE packaging them and RVM switching between them.

uhm ..... and how should this work? darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-ruby+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-ruby+help@opensuse.org