----- Original Message ----- > Hi
> On Wed, Dec 5, 2012 at 4:04 PM, Matthew Miller wrote: > > 1) Fedora is big enough that we have concrete situations where one > > size > > > doesn't fit all. Puppet being broken on F17 (and probably F18 as > > well) > > > is a fine example of something within the distro itself. And, as a > > > platform for development, offering more version choices to our > > users > > > would be a strength. > > While I can see why it might be useful to SC overall, why isn't > packaging two different versions of Ruby an option for this specific > case? > Rahul Packaging two parallel versions of interpreters brings not only the burden of maintaining them, but also the work to make them not conflict. E.g. renaming binaries, checking shebangs all the time, etc. With SCLs, this is much simpler and more transparent (my POV). I don't think Fedora's Ruby-SIG is going to do that. General Ruby vs. SCLs comments (explained for non-Rubyists, too :) ): In Ruby world (yes, Ruby is probably the first that comes to mind when talking about SCLs), SCLs make great sense. Considering a standard Rails application, say Redmine [1], it is custom of the upstreams to lock these applications with certain versions of Gems. This is done using Bundler [2] (it doesn't really bundle libraries, but locks the dependency set) via Gemfile, resp. Gemfile.lock. Gemfile specifies general dependencies, while on installation of these dependencies, Gemfile.lock is produced that lists the specific versions of the installed dependencies (and their dependencies etc.). This is great for developers, as they can just pull the app from git and install precisely the same set of dependencies as the other people who were developing (or deploy it with the same set of deps, too). It is of course not so great for packagers, as the upstreams say "these are the versions that we support now" and we can never know whether Redmine will work with the versions we have in Fedora (yes, you can run unittests, but you can never be 100% sure). But let's say that Redmine works with versions we have in Fedora and we package it, creating Gemfile.lock for the package. But what happens when we update a dependency of Redmine (judging from its Gemfile, I'd say it'll give more than 100 Gems)? So when updating any of these packages, we have to retest and rebuild Redmine (to regenerate its Gemfile.lock). We can probably do this while having one application like this, but it starts to be unmanageable with just couple more similar applications. And you can't solve this problem by having multiple versions of Ruby, you'd end up having tons of multiple versions of Gems, too. (This starts to be nice with the whole "append version to name, so that the packages don't conflict" RPM solution.) This issue of packaging applications with Gemfiles into Fedora is periodically being discussed on Fedora's Ruby-SIG, so far with no real outcomes. Please note, that the Ruby community is sometimes very aggressive to distro packagers, saying that distro packaging of Gems is useless etc. Generally, the world of YUM/RPM and world of Bundler/Gem are just very divergent by their nature and don't play that well together, as other packaging ecosystems do (it seems to me that Python community is 100 % more packager friendly than Ruby). Now back to SCLs. Considering Redmine, you can build the whole stack of its dependencies in SCL, while not polluting the system Gems with hybrid rubygem-foo23 versions. Rather, you create, say, "redminescl-rubygem-foo" package in the version Redmine needs. Not only it tells you right away where it belongs by its name, it also means you are free to do whatever with it's versions, because you are detached from Fedora. So if someone comes and says "hey, I want to package this Ruby/Rails/whatever app for Fedora", you just tell him to do the collection and maintain it. Now I'm not 100 % sure we should allow anyone to create any SCL in Fedora, but it would certainly make sense for some cases. Generally, SCLs solve these problems: having multiple parallel versions of libraries (or better say "stacks") and more importantly detaching the application's lifecycle from Fedora's and including everything specific that this application needs (specific versions, etc.). -- Regards, Bohuslav "Slavek" Kabrda. [1] http://www.redmine.org/ [2] http://gembundler.com/
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
