A lot has been said about why we perhaps should not package/bundle Rails. Can I throw out a question to everyone, playing devil's advocate. What do you feel are, if any, the compelling reasons for providing Rails as a Solaris and/or Indiana package? I stress the 'compelling' as the world is full of edge cases that are really not at all compelling.
Thanks Amanda Prashant Srinivasan wrote: > Thank you Jyri + other web stackers for taking the time comment on this > proposal. > > Please see inline . . . > > Jyri Virkki wrote: > >> Prashant Srinivasan wrote: >> >> >>> Given that rubygems support in Solaris is already present, we have three >>> options to support Rails(and other gems). >>> >>> (1) Use Solaris packaging exclusively(ie., gems not allowed). >>> (2) Get Solaris and Rubygems to co-exist. >>> (3) Use Rubygems exclusively. ie., don't bundle Rails. >>> >>> >> As you say, (1) isn't at all a realistic option. >> >> #3 is cleanest and easiest. But is it adequate? Some thoughts.. >> >> The ease of installation isn't any different: "gem install rails" >> vs. "pkg install SUNWrails".. not much there. >> >> > Agreed. > > >> Ease of finding it.. depends on the audience. For someone used to >> managing the system via pkg it's probably easier to stumble upon the >> package than to know about gem. But really, it's the Rails developer >> you're after here - and they sure know gem (more than they know pkg). >> >> > > Okay. > > >> Supportability. If(?) you're planning on supporting Rails, having the >> package is good since you need a known/fixed set of bits to support. >> >> > > That's not applicable - at least for this particular effort. > > >> Offline installations. Some environments (typically for security >> concerns) may only allow installations from official media, so online >> gem install would be out. pkg install too of course, but if there is a >> package it's possible to build a DVD containing it. Realistically that >> kind of environment is probably not the target market for Rails, but >> worth a thought. [But you could bundle the gem in the DVD as well, >> just not as conveniently.] >> >> I'd lean towards starting with #3 (via gem only) until there is >> concrete demand for a package. >> > > Okay. And this is something that others on this chain seem to be > saying too. > > >> On the other hand, I remember that's >> what we said last time and now you're looking into Rails, so it's very >> possibly concrete demand already showed up, which is why you're here.. >> >> >> >> > > Well, I'm a stubborn guy ;-) But seriously, last time we had this > conversation we were looking into a variation of what Amanda hinted at > yesterday - ie., Use Solaris packaging to wrap around the gem command - > that has it's show-stopper problems. Next we tried to snapshot a stack > for Solaris, this is not compliant with rubygems . . . so we decided to > put rubygems into Nevada, and leave the "gem install" as a trivial step > to be executed by the end user. > This is the next iteration of that conversation. > > >>> We're left with the possibility that files packaged by Solaris will be >>> updated by gems if an end user decides to use Rubygems. >>> >>> >> This option is not an option. There can't be two supported mechanisms >> (packages & gem) stomping on each other modifying the same files. Only >> one delivery mechanism can own a given file. >> >> If you decide on packages, it needs to be done in a way that achieves >> #2 (peaceful coexistence). >> >> Debian seems to have achieved this so no reason OpenSolaris can't. >> gem-installed content goes under /var, package-installed content goes >> under /usr and they seem to coexist ok (I've played a fair amount >> with gem vs. packages on debian, but only at a shallow level. I urge >> you to experiment with it in more depth). >> >> >> >> > > Well, the Debian position is rather strong. They don't believe that the > gem format is ideal since it is not FHS compliant. They also disagree > with the concept of using "require_gem". So, if you're using Debian, > it's apt-get all the way, or rubygems all the way. > > This is really position #1 in our discussion since there no > interoperability across gems and Debian Ruby packages. IMHO, the Debian > position is problematic: > > 1. This one probably happened too recently for the Debian folk to take > into consideration while figuring out how to work with Ruby. Rubygems > is now in Ruby 1.9, as opposed to earlier when a Ruby itself had no > packaging preferences. So if you're in the repackaging business, you're > fighting an upstream battle since a Ruby application developer is > probably just going to provide a gem(the best way for his application to > reach as many Ruby users as possible. And the only way to reach _all_ > Ruby users, starting with 1.9. > > But Debian does package Rails(an older version) - this leads to more > end user confusion on how to install Rails than there should be. I > remember going through a Debian HOWTO that had two parallel tracks, ie., > how to you get Rails installed if you want to use apt-get, versus what > you had to do if you want to use gems(and with no intermixing. ie., you > can't use "apt-get" for one step and "gem" for the other). > > 2. If your Ruby program depends on a library, and announces this > dependency as a being on the gem form, it doesn't matter if you have the > library installed in a non-gem form, the program wont run . . . so this > is another problem they can run into. > > 3. If someone wants to maintain their own packaging format, they're > asking end users to be locked in to their system, and they need to > provide up to date versions in a timely fashion to prevent the users > from leaving. This is not a problem if the custom packaging format is > compatible with Rubygems, but otherwise(ie., in the Debian case), it's > time consuming to keep fast moving packages like Rails up to date. > > > >> >> >>>> Does this create any dependencies to MySQL and/or Postgres packages? >>>> >>>> >>> Yes, it does. I'll update the imported interfaces list in the ARC case. >>> >>> >> So does it mean the SUNWrails package now depends on both MySQL and >> Postgres? Those are big components, there is no reason to demand that >> the user must install both if they want Rails (since typically they'll >> use one or the other, not both). >> >> Can these be separated into separate units, such as how PHP does it? >> (SUNWphp524-mysql vs. SUNWphp524-pgsql) >> >> > > Yes, this is feasible. > (after we've defeated the 800lb packaging Gorilla that we're wrestling > with ;-) > -ps > > >> >> > > _______________________________________________ > > > webstack-discuss mailing list > webstack-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/webstack-discuss >
