[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Introducing the patchadd binary patch toolchain
On Wed, Apr 29, 2009 at 8:40 AM, Tonnerre Lombard
> Salut, Elad,
> On Tue, 28 Apr 2009 17:22:02 +0300, Elad Efrat wrote:
>> > The tools
>> > =========
>> > The tools, which have been added to pkgsrc/sysutils/patchadd
>> > recently,
>> So you've added an incomplete tool to update the system into mainline
>> pkgsrc? out of pure curiosity (and since this is a tool to update
>> NetBSD, supposedly), did you discuss it in a public forum as you do
> I did discuss this with other developers.
> And as mentioned before, this
> tool is working, it's just that some features which people may want are
> already missing. My goal was to get this out in time for the 5.0
> release so we can start rolling binary patches by now.
Tell me if I get this right: I told you a tool for updating the
system, not just patching it, that includes all of patchadd's
features, and more, exists and is working. Yet, you decided to go
ahead, write a new tool with less functionality that is limited to a
subset of actions when updating a system, import it to pkgsrc after a
discussion that I'm guessing didn't even take place in a public forum,
and now you're implying that you're going to shove binary patches down
the throats of all NetBSD users?
>> > consist of the following tools:
>> > - patch_add, a tool to apply binary patches,
>> > - patch_delete, a tool to back out a patch added without -r, and
>> > - patch_info, a tool to display the list of installed patches.
>> Why are they all separate tools and not a single one?
> To mimic the behavior of the pkg_* tools.
>> also highly recommend you think about common uses for updating tools
>> (because hopefully that's what we want - a *single* tool to be used
>> to update the system, and not a confusing collection) -- therefore,
> Please note that "Backing out a patch" and "What patches are
> installed?" are different use cases than "Install a patch".
So are "list all files in a directory", "list all files in a directory
in long format", and "list all files and their inode numbers". And
yet, we have the technolog to combine all these into a single tool.
>> you should think on how you can make life easier for people who
>> release patches, write security advisories/notes based on the
>> patches, and so on.
> They only create the patch files and regen the index.
That's more overhead, and of the worst kind: people time.
>> Out of personal interest, can you elaborate on why you chose to write
>> a tool from scratch, given nbupdate (agc@) and haze (mine) freely
>> available? also, can you elaborate on why you prefer binary patching
>> to simply distributing replacement files?
> At some point maybe. Right now I'm too busy.
You're too busy to explain why we want something one way, but you're
not too busy to implement your ideas and put them in pkgsrc?
Main Index |
Thread Index |