[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Patch packages?



Leif Pedersen wrote:
>but seriously, it seems like overkill to have a whole package for (usually
>tiny) patches

No, you have it backwards.  It's overkill to recompile the whole
system just for (usually tiny) patches.

A package is the small simple solution; I don't know what you mean
about a "whole" package; it's just a tarball of the changed binary
files.  Remember, not everyone compiles the whole system at all, and
I'd guess most never compile more of OpenBSD than the kernel.  It's
simply impractical in many cases (again, my IPX, or an installation
with limited disk space).

>...and if it's something big, you'll do more work than
>installing current.  Especially when considering:  what about a patch on a
>patch (esp in the kernel)?  So ya distribute the latest kernel...but then
>what about the required userland support?  Pretty soon you might as well
>upgrade to current.

Nobody is suggesting packages for changes to -current.  We're talking
about tracking -stable here.  -current is irrelevant here until it
becomes the next release.  This would be silly for -current.

As for a "patch on a patch", you could simply overwrite the old files
with the new ones.  Yes, this might take some tracking at the packager
end (patch version numbers would be useful), but anyone with
experience with other binary patch systems (such as Sun's) should be
able to put this together.  A first pass would just overwrite files as
needed, and expect people to apply all patches in the correct order.

If I had the hardware, I'd put it together, but I don't.
-- 
============= R o b  F u n k =============|======> funk+_(_at_)_osu_(_dot_)_edu <=======
   "A microscope locked in on one point   | rfunk_(_at_)_wks_(_dot_)_uts_(_dot_)_ohio-state_(_dot_)_edu
Never sees what kind of room that it's in"| rfunk_(_at_)_funknet_(_dot_)_net
    -- Chris Mars, "Stuck in Rewind"      | http://www.funknet.net/rfunk




Visit your host, monkey.org