On Fri, 2006-06-02 at 16:33 -0700, Philip Brown wrote:
> 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.

A missing capability of having source package reduces community
involvement in development of a package. In Nexenta/Debian you can do:

apt-get source gnome-panel

than fix, rebuild and re-upload to "unstable" APT repository. Well, in
Nexenta we are not there yet (re-upload part does not work yet), but we
will be there soon.

Similar things with RPM & yum.

And sure, having patches bundled with a particular upstream tarball will
eliminate a mess I'm seeing.

> > 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.

Right, SVR4 could be extended with scripting stuff etc. But also pkg-get
and remote repository needs to be extended as well.

> 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.

sound like debdelta which has been around for years is what you are
looking for.

> 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.

Erast

_______________________________________________
opensolaris-discuss mailing list
[email protected]

Reply via email to