On 6/1/07, Giles Turner <[EMAIL PROTECTED]> wrote: > On 6/1/07, John Sonnenschein > <[EMAIL PROTECTED]> wrote: > > On 6/1/07, Giles Turner <[EMAIL PROTECTED]> wrote: > > > > > I feel that you will never ever get what Ian is > going to do from the > > > OpenSolaris community. Not from Solaris users. > Period. > > > > > > > This doesn't strike you as a bad thing? That's a > sign of a lack of > > transparency, and without transparency what you're > doing isn't open > > source. > > Which is why I am all for that Ian is trying to get > done. No > repositories because current solaris toolchains do > not support them,
Huh? Blastwave adds one thing (pkg-get script) and uses a repository model. One could argue that packages that are generic to Solaris 8 on upward aren't as well integrated as packages that took more advantage of out-of-the-box dependencies rather than providing their own (probably not possible at Solaris 8, but there's IMO enough stuff in Solaris 10 and later that it should be possible there). But that's a separate problem. Anyway, the SVR4 packaging mechanism isn't inherently incompatible with a repository-based distribution mechanism. The boundaries between packages might need to be drawn differently. And one or two minor additional features might be needed; but the mechanism is for the most part extensible enough to handle that (extra attributes in pkginfo file; might need hooks for additional scripts though). More important, the testing and distribution process would have to be redone. > existing tools that do that outside Solaris space are > pooh poohed, the > repository model of distribution pooh poohed, solaris > users pointing > to the patch system for system software management > which is hardly > transparent and coupled with the fact that even some > solaris users are > not happy with those tools and the service that > provides those patch > packages and not willing to accept an open source > toolchain > alternative much less an alternative infrastructure > for that > toolchain... The patch mechanism works, if not well sometimes (and even if there's a history of sucky tools for patch management). With a good patching tool, it would work reasonably well. If you view a patch as what it is, simply a set of partial packages that overwrite the corresponding files of existing packages, plus some scripts to tweak whatever needs it, the only real differences I see between that and a repository model are: * (+) the patches take care of treating dependent updates as a unit, and of any other smartness needed to make that work * (+) since the patches aren't necessarily entire packages, they're usually updating less files. If the mechanisms were improved, that could be faster than updating entire packages. And sometimes it might make it possible to avoid reboots that would at least be advisable if entire packages were updated. * (+) probably more testable * (-) patches seldom add new packages. One can often work around that by grabbing packages from a newer xx/yy of the same minor version. * (-) two separate sets of commands, and at least somewhat harder to use * (-) less amenable to online updating There's something else to consider: as it is now, patches other than security/recommended require a support contract. With a repository, what would happen? Seems if the OS gets given away, then support can't reasonably be free too... I'm certainly not sold on the repository approach, but if it gave me at least as good results in terms of speed, reliability, uptime, etc, I don't guess I'd much care in the long run. > Solaris users are in the way of OpenSolaris becoming > open source > because they depend on the Sun Microsystem's > commercial Solaris > environment and do not want anything in OpenSolaris > to change save for > more drivers and kernel features that do not break > their precious > environment. Some of those very solaris users are > also decidedly not > willing to pay for what they view as broken and > shoddy tools/service > and yet they are not willing to accept any other open > source/transparent alternative. I say they better > just stick to > Solaris and leave OpenSolaris alone. Nonsense. You want OpenSolaris going down different roads than Sun's distro? Use one of the other existing distros, or create a new one if that makes you feel better. But don't expect anyone to care about it unless you can show how it's different from all the others. And insofar as most of OpenSolaris (I suppose Sun could leave bits they didn't want - at the level of executables or libs or modules not depended on by anything they did want) will continue to be the basis of Solaris, I think there are limits to how much one could reasonably expect to break compatibility. Certainly not for user or 3rd party apps or drivers. But maybe user interface stuff could be changed a fair bit, although it would certainly require existing users (who to my mind are worth more than _potential_ users (see expression "a bird in the hand...") to get used to the changes, _unless_ it was done the way I've tried to suggest, namely a few more settable defaults and some "personality" scripts that tweaked those in one of a number of ways at install time, providing for choice of default shell, default PATH, and so on. This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
