On Thu, Jan 25, 2007 at 04:51:02PM -0500, Glenn Fowler wrote: > putting everything in one dir will eventually reach unresolvable > version interdependency conflicts > > /usr/bin/foo(3.4.5.6) requires /usr/bin/bar(3.4.5.6) > but /usr/bin/huh(1.2.3.4), which uses /usr/bin/bar, currently > only works with /usr/bin/bar(1.2.3.4) -- so bar will hold up > moving to the new foo
We already have this problem with things like Perl (we have two versions in Solaris now, and /usr/bin/perl can [and does!] only refer to one of those). I don't see why we couldn't follow that model in general. Now, version stability may be an issue, so that having shipped /usr/bin/foo(1.2.3.4) in Solaris 5.x we may not be able to change /usr/bin/foo to be version 3.4.5.6 until Solaris 5.x+1 or higher. > or, /usr/bin utilities from different distributions might require > specific but conflicting semantics from another /usr/bin utility > going by the same name in both distributions, oh, say maybe > /usr/bin/ksh That would mean they have conflicting names, so multiple versions (in different locations) of foo would have to be shipped. What serendipitous discovery does is make the default environment maximally useful to the average newcomer. Version dependency issues would exist with or without it, but newcomers are more likely to accidentally use the generic 'foo' instead of the specific version that they might need and then get bitten when a future, backwards- incompatible version of 'foo' replaces the generic 'foo' in /usr/bin. Ideally FOSS developers will avoid backwards-incompatible changes, but their release schedules will generally be different from Solaris' so such problems are not entirely unavoidable. Nico --
