On 12/01 10:55, Stuart Henderson wrote: > On 2010/11/30 16:35, Jeremy Evans wrote: > > > > 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). > > > > Jeremy > > I'd lean towards 1) unless conflicting things are required as > *build* dependencies, then some fudging would be required in order > to get bulk builds done.
Splitting ruby gem ports by version should not introduce conflicts, as they install into directories that include the version name. The one exception is the binary files, which we can probably just @comment out in the PLIST of the lower version. If I have to split a ruby gem port I'll be using @option no-default-conflict and @conflict ... in the PLIST. Jeremy
