On Tue, Nov 30, 2010 at 04:35:37PM -0800, Jeremy Evans wrote: > It started with me wanting to update rack so I could import rainbows (a > ruby webserver). But updating rack required updating rails. Updating > rails required an updated version of thor. The in-tree version of merb > depended on an old version of thor, so I had to update Merb (the new > version of merb doesn't depend on thor). merb_datamapper depended on a > later version of DataMapper than what was in the tree, so I had to > update that as well. > > Anyway, here's a gzipped diff for the current ports and a tarball with a > bunch of new dependencies. > > Tested on amd64 and i386. Looking for OKs. > > Unfortunately, updating ruby ports is going to start getting even > uglier. Many ruby projects are starting to restrict their versions to > specific ranges (e.g. ~1.1.2, which equates to >=1.1.2,<1.3). I would > expect that we will soon be in a situation where we'll have two ports we > want that have conflicting dependencies, where the version ranges of > dependencies they support will no longer overlap. That will leave us > with the following options: > > 1) Split the dependent ports into multiple versions. > 2) Fudge the version spec on one of the ports so that the dependency > version overlaps (after checking that things work). > 3) No import/update the port. > > Any thoughts about how the situation should be handled? I'm leaning > toward option 1).
I would prefer option 1) at least for a handful of gems. For example I would prefer two version of rails since rails 3 and rails 2 are not compatible and it needs some work to update from rails 2 to 3. On the other hand option 2) can be used to fix some too restrictive gem specs. I guess such "broken" specs will get more common. I can't test the rails 3.0.3 update at the moment since my rails project is not yet rails 3 ready. -- :wq Claudio
