> For a server, centrally managed and installed > libraries and packages is a must. The same goes for > desktop users (ala SunRay).
Why? You didn't make that clear (at least not in a way I could decipher.) I deal with thousands of servers and don't see this as being an issue. Central management, sure - but libraries? No. Unfortunately, dealing with thousands of servers running various OSs, central libraries for applications are the root cause of most of our problems. Hence my original message. In an ideal world, I can understand. You push updates to all of your *insert OS of choice at specific revision* that updates the bdb library for instance (oh wait - that isn't included in Solaris/OSOL), and the applications linked dynamically to the libraries that get updated continue to function flawlessly. I can count the number of times on my hands deployments have gone down like that. Generally I find myself "testing" updates to non-OSOl/Solaris provided libraries on servers, finding that half the software compiled against X Y Z library has broken, and I need to recompile/debug/patch it all. With the system I outlined, let's say you had a Postgres package. All non-os-core libraries would be provided as a part of it. Maybe one of these non-essential libraries has a flaw that gets corrected. Ok, no problem, you download the updated package (or create your own, whichever the choice may be) - rebuild it with the updated software, and then redeploy the package. You *know* it's going to work, regardless of where you deploy it, because the Solaris base libraries 99.99% of the time don't have weird API changes and such to mess up things linked to them. So as long as your package itself is "ok", it should deploy just fine, to however many gazillions of servers you want. Especially if you keep your build machine at the same revision of your production machines (as you should) - you'll know the software is going to work. Try upgrading gettext on a system with php built on it, or other such tests. It's normally not pretty. I can understand core OS libraries, that the OS depends on for operation (maybe threading libraries, or SSL libraries, or etc...) being dynamically linked to. I'm talking about all these extraneous libraries we (as system admins/developers/whatever) need to compile and shoehorn onto the server. Most library developers aren't as kind as the Sun engineers, backwards compatibility is seldom flawless. Again, not speaking about core libraries included with the OS itself - I can understand dynamic linkage to them. I'm talking about application-specific required libraries that are NOT a part of the core system. Such as BDB. I think my core point isn't so much about the method to the madness (I'm sure much more intelligent people than myself can come up with a much more feasible engineering solution) - it's more of a usability-perspective suggestion. I have lots of issues building things on the servers, because invariably X software requires Y library, etc. Things like OpenPKG/Blastwave/SunFreeware "take care" of this, but then I am stuck with whatever options they choose to compile with. By my little hybrid ports/package system, you would be able to build the packages with the options you wanted, and be *sure* your library versions were compatible. The only issue I can foresee (and suspect is why you made your original statement about centrally managed libraries) would be security updates - but this really should be an application management issue. The flaws are application related. If the flaws are OS related, then as this system would NOT be replacing the core system libraries, the OS update would still be effective. This works well even now, due to the fact that Solaris/OSOL maintains good backwards compatibility. Also, Sun Ray is thin client. That's not a "typical" desktop user. The packaging model I described wouldn't be a problem in thin client deployments either. You'd just be installing/updating/whatever packages on the server. It'd be transparent to the client, just as it should be - that's the whole point of central management/thin desktop solutions. > Individual desktop users may have different needs. Sure, of course. > Someone could provide a tool that did this now using > the existing Solaris Package Format. Or you could use > OpenPKG... I've used it before, along with blastwave and all the rest. The problem is, they tend to "replace" even the core OS libraries. This is overkill, and unnecessary. Also, they don't impliment much of the functionality I described. They are more akin to debs/rpms. This isn't what I was shooting for, I'm surprised you didn't realize this. I don't want to be stuck with Joe or Moe's build that includes only X Y function, when I need only Y and Z. > Really, almost everything you ask for is answered by > OpenPKG, which supports Solaris. In fact, if you > combine it with apt-get, you have a nifty little > solution. Really? I didn't see the ability to pick what options I want on each piece of software. I also see a bunch of dynamic libraries being installed, they just happened to be in different locations. The same issues with dynamic library upgrades applies here, it's a PITA. Upgrade a library and half of your other packages might suddenly die. Then you have to go through each of them figuring out what went on.... > Since OpenPKG uses it's own package database, etc. > you can easily install and remove libraries and > applications without bothering the base operating > system install, and because all of the applications > live under their own directory tree, there are no > conflicts with existing installs. Yes, you don't bother the base system at all, I noticed that. It provides it's own "base system" and operates on top of that. It's no different than the current solaris package management, it's just another layer on top of it, making it easier to handle the plethora of libraries OSOL/Solaris does not already include. This isn't even close to what I was suggesting. Thank you for your input, it is valued (please do not get the impression I am not listening) - but none of that really answered my question, and the point which you debate (concerning the libraries that are not part of core) was not explained in a way I can understand. My apologies if I have misunderstood something! Thanks, and looking forward to your feedback, David This message posted from opensolaris.org
