> 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'm glad you came. Hi! > > 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. > That sounds wonderful. > > 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. > Yes, lots of people have had that question, myself included.. > 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 That's been witnessed by countless people. Ever heard of "dependency hell"? It's a common phrase when describing linux distributions and their attempts at updating/installing/changing software. Been there, done that.. > > 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 > I can somewhat understanding this, assuming bar 1.1 really was "better". > 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" ;-) > Also simplying the package maintainer's 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...'" > This is what I want to avoid, and why I have so many problems with various package management systems. Dependencies suck! > 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. > Ok, still following you... > 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. That's quite cool. > > 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. I can understand. > 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. Makes sense. I think a good way to integrate this work is make sfw modular, and have some kind of update mechanism in place for it. Give non-sun people access to the repository/update mechanism, as well as tools to create/work on/etc packages. Have a staging system in place, so it passes through various levels until it's certifiably working/not bugging out. Then give it final approval and pump it out to the world. It sounds like a lot of what Blastwave is already doing could be applied here, if not integrated directly. I'd also like to add, as an additional feature it would be quite cool if the update/install/whatever tool allowed an administrator to specify options that aren't a part of the package already. In this case, instead of fetching the default pre-built package, the source along with the build information/whatever would be downloaded, and a prompt would come up asking what options you wanted etc, and when you finished it would be built and installed. Much like ports, except make binary installs default unless the admin specifies options outside the default for the package. This would solve my biggest problem with Blastwave. Thanks for coming and giving a clear and calm statement answering the question a lot of people have been asking. I know it clarified a lot for me. Cheers, David _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
