On Fri, Jun 02, 2006 at 04:19:23PM -0700, Erast Benson wrote: > The problem I'm seeing is that SVR4 packaging system wasn't developed to > inter-operate with upstream tarballs and patching system is not an easy > one to enable. At least it is not as easy as with Debian or RPM. That > means patches for particular upstream project A are not part of A SVR4 > package itself and instead stored separately somewhere. >
The following is in the context of the solaris "patch system", not other "patch systems": (binary) patches, are to update binaries. Binaries are the results of a particular source tree. (at a particular version) "upstream tarballs" get integrated with a source tree, not binaries. An appropriate technical person should be merging the source together, and determining if a binary "patch" is needed, or whether a full new release of a package is appropriate. SVR4 packaging is primarily geared towards binaries, not source trees, IMO. Personally, I dont see that as a problem. see below. > This is what other distributions do, their *source* packages usually > contains upstream tarball + set of distribution patches on top of it. > And sooner or later those patches will migrate to their upstream or > simply rejected. Nothing says that opensolaris has to have "source packages". But if it does: the SVR4 packaging system could still be used for it. Switching gears a bit, though: last I heard, debian does not have a binary patching system. just a source code packaging system, that primarily exists as "original tarball + set of patches", as you noted. I'm not sure I'd call that a "patching system" for source code either. more like a pre-bundled, pre-determined patch set + autobuilder. _______________________________________________ opensolaris-discuss mailing list [email protected]
