[Mongrel] The Gentoo/FreeBSD Plan - reloaded

Filipe filipe at icewall.org
Mon Jan 15 08:29:39 EST 2007

On Fri, 12 Jan 2007, carmen wrote:

>>>the ebuild is almost totally empty, besides this line:
>>>.inherit ruby gems
>>>im thinking they could proably factor this line into the eclass, since presumably rubyforge has a naming convention:
yes, it has. Mongrel is a litle diferent from other projects, but still it has a naming convention.

>>>you might wnat to look into something similar. i like to think of the package manager as a wrapper, not an un-networked custom unwrapper/rewrapper and
>>>hope everything ends up back in the same box (and usually with competing version numbers and optional modules it doesnt)
>> the other important reason for hooking into gems, besides maintainer sanity, is to allow the user to mix and match between installation methods. what happens when the user installed mongrel bypassing gems, then installs camping? im pretty sure it installs mongrel again, and then when they get a bug they dont even know which version is being used..

Yes, it reinstalls. But the way I think is this: if I'm a user and want to get along with debian version of mongrel, that's fine.
But if I don't like it (and I hate debian's packages), I can install everything from rubygems and be happy too. But now, mix the two methods really means trouble for me.

> the Gentoo method isnt perfect - it fails in the inverse scenario where youve installed everything via gems, then want to install something through portage that depends on installed gems (stuff gets reinstalled). the other problem is its tied to hardcoded version numbers in the ebuild filenames. theres no way for it to discover that newer versions of the gems exist. does freeBSD solve either of these problems?

Well... my watch file again:

Maybe it helps.

filipe lautert

filipe { AT } icewall.org
Linux User        #279798
Jabber  lautert at jabber.ru

More information about the Mongrel-users mailing list