On Fri, 1 Jul 2005, Joerg Schilling wrote: > Blastwave unfortunatly currently is a binary "only" distribution. > I would be happy if we could have the knowledge from Blastwave > archived inside a source package system. I would be happy if this could be > done with sps as sps is easy to adopt.
That has always been my biggest problem with Blastwave / sunfreeware. Something like that, but oriented around providing both binaries and reproducible (but customizable when needed) builds of those binaries would be a Good Thing > > The packaging structure for Solaris isn't going to change, though it > > might be possible to add support for one or more additional packaging > > methods that other distributions could use. That seems like a tough > > sell, though - properly maintaining one set of packaging data is > > enough work already, and nothing stops a distribution from discarding > > usr/src/pkgdefs in favour of its own solution. > > In case you would e.g. write a hypothetical rpm implementation on top > of the AT&T/Sun package database, this could work. If you just contemporatily > use unrelated package managers, you will get into trouble with overlaps. Normally (to the extent that using rpm on Unix is ever "normal", even if some very large Sun shops do it ;-) what you do when using rpm on top of SysV packaging is install the base system using SysV. After you get rpm on there (either from source or from a SysV package) you then run scripts which generate fake rpms that provide all the dependency information which represents by the Solaris-packaged stuff. You install those fake rpms, then do the rest of your application installs on that box using rpm. That works, as long as you stick to rpm from there on out. It also sometimes gets messy to manage if patch changes shift dependencies (ie, a new patch adds a new feature that should be registered as a dependency, but which isn't because it wasn't in the original package version). That's kinda an inherent complication due to the Solaris "package management is one thing, patch management is something else" distinction that's counter to rpm's "patches are built into packages and you just manage packages" approach The Rutgers stuff is probably the most thorough publicly accessible info source for rpm on Solaris. See <http://rpm.rutgers.edu/>. later, chris _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
