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 > >
