Laszlo (Laca) Peter wrote: > It seems that most common concern with installing the FSF/GNU binaries > in /usr/bin is that they will become obsolete and [some] users/admins > want to use their own, newer versions instead, which they can only do > through link farms or aliases. > > I think this is a valid concern, but not an architectural one and > is more related to Solaris processes and resources and not necessarily > an issue for opensolaris based distributions in general. That said, > I agree that Sun should do something about this. Shipping obsolete > external open source packages is clearly a disservice to customers. > The solution should not be keeping them elsewhere so users can ignore > them, but keeping them up-to-date. > > As James stated. 'up-to-date' isn't always a solution.
At least not until these packages stop using compile-time options. Sun can ship uptodate versions, but unless they are also going to ship every permutation of compile time options, it won't work. Also sites don't like to move to a new version till they do so on every platform. So even if Sun was first to every new version, Sun would need to also include the option to install any older version? Clearly both of these are impossible, so the need to override this stuff remains. -Kyle > Laca > > On Tue, 2007-01-30 at 22:00 -0800, Richard L. Hamilton wrote: > >>> Except that historically /usr/bin isn't all of a >>> single provenance. So >>> you want to take a snapshot of /usr/bin as it stands >>> today and "copy" it >>> to some other location where we'll only ever add... >>> what? nothing? >>> hings developed at Sun? or in the OpenSolaris >>> community but not of some >>> other FOSS or even proprietary provenance? >>> >> Past a snapshot at the present time (give or take some things that >> arguably shouldn't have gone into /usr/bin in the first place, like >> the >> GNOME stuff), only things added specifically via Sun or OpenSolaris; >> that way, they would not simply be out-of-sync snapshots of FOSS from >> elsewhere that sites might wish to use their own builds of, >> whether to be more nearly current or to standardize on specific >> versions >> enterprise-wide. Typically, I'd see those as either not conflicting >> > >
