Hi folks, I was informed there was a bit of a broohaha over here, about packaging up open source binaries for solaris and opensolaris. So, as the author of pkg-get, and the creator/leader of the CSW packaging efforts living on blastwave.org, I thought I'd poke my head in and wave.
*wave*. I've been skiming through some of the archives on this subject thread. I'd like to think that I can offer a calm and cool response to any outstanding issues or questions reguarding blastwave/CSW packaging. I'm on too many mailing lists as it is, so this will probably be a short-term (few weeks) visit :-) But I'll do my best to pay attention during that time. At this point, there's only one clear thing that i'm not sure people have explained: Why blastwave offers packages that are "redundant" to some sun ones. This issue came up waaaay back 5 years(?) ago when I started things off. We initially tried to build on top of Sun shipped stuff, which at that time, was all living in /opt/sfw. It didnt work. The libs themselves worked fine enough. But the problem is that open-source software is very undisciplined about any kind of binary or API compatibility. The majority of new stuff, always seems to demand the latest "new stuff" from the other projects that it compiles against. This means that if we wanted to offer foo 2.0, which depended on bar 1.1, but sun only shipped bar 1.0 ... we were stuck with either not offering foo 2.0 at all, or offering our own bar 1.1 for foo 2.0 Then, if we were shipping bar 1.1 ourselves, it made no sense to have our other stuff that also used bar, compile against sun's bar 1.0, when we had the newer,better,whatever bar 1.1 Now, eventually, sun caught up, and shipped bar 1.1 But by that time, we were already shipping packages that depended on CSWbar, not SFWbar. It would be really bad policy to go back and force-recompile and repackage CSWfoo to depend on SFWbar, when SFWbar is going to be out of date again soon enough. At an early point, (mostly for laziness reasons :-) we tried to go with, "use SFWbar, unless we need a newer version, then compile against CSWbar". But this eventually dwindled to such a small percentage, there was no longer any real gain to depending on the SFW versions any more. So I made the decision to "simplify the user experience" ;-) This also hopefully gives end users/admins the cleaner option of, "If you like the way CSWgnome looks, you can standardize on it, and eventually pkgrm SFW/SUNWgnome* cleanly, without worrying about, 'oops, I can remove all those sun gnome packages EXCEPT those special ones over there...'" There's no clean way to manage that last "EXCEPT" piece. It was cleaner to just treat Solaris as the pure base OS, and ignore all the SUNWgnome/SFWgnome type stuff. This becomes even more of an issue in the fact that we support our latest version of gnome, on sun's oldest officially supported OS release: Solaris 8. Sun doesnt support SUNWgnome fully on sol8. (last time I checked anyway). We do. Given that we have to do the full gnome dependancy build on sol8 anyway... it would make life far too complicated to ship two very differently linked versions of gnome; one for sol8, and one for sol10. The single version approach is actually beneficial to the USERS, as well as the blastwave maintainers!! This way means that our users can NFS-export out a single /opt/csw, to ALL their solaris 8, 9, and 10 machines, and have gnome work *exactly the same way* on all of them. _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
