tech-userlevel archive

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

Re: Introducing the patchadd binary patch toolchain


On Tue, Apr 28, 2009 at 09:25:52AM +1000, Giles Lean wrote:
> How do you plan/do you plan to identify patched binaries?  Will
> their ident(1) strings be changed when they're patched?

It's handled the same way packages are - in /var/db/patches.

> >  - Arbitrarily named bsdiff(1) patches lifting the file from old to
> >  new.
> I would think about including the whole new file; that makes it simpler
> to get the new files out, e.g. for experimenting to see if they fix a
> problem.

Backing out is not a problem, that's what patch_delete is for. The entire
file is preserved in the patch directory.

> Hmm.  There's a bicycle shed there.  I'd recommend choosing some
> guidelines (any guidelines) about how patches are named.

Yes. I've given my recommendation, but this is not an issue the tool
can solve.

> I've seen patches with >50 replacements or updates on commercial
> Unixes, FYI.

I know what you mean. :-P

> Patch dependencies are a can of worms, including patches that are
> applicable to only some ports, patches that require different
> dependencies on different ports, new revisions of patches that
> alter the original dependency list, and more.

In fact, my tool currently follows the guideline of different patches
(and different patchdirs) for different ports.

> What about patches that are co-requisites (i.e. that must be installed
> together) or patches which have alternate sets of patches which will
> satisfy their dependencies (a case to be avoided if possible!).

Should we encounter the problem, we can release a new format version
which fixes the problem.

> Which brings a new question: can the patch information be updated
> without having to update the version of the patch?  e.g. if a patch
> is put out but is missing a dependency, it might be desirable to
> update the patch information, but not require users to install a
> new version

In that case no download tool would see any reason to fetch the patch,

> I'd recommend a guideline of including a URL that links to a description
> of the patch which can be updated as needed.

That would make the patch_info output highly bogus.

It would be unproblematic however to add URL fields for informational
purposes; it would be a tiny patch to patch_info.

> What about patches that are architecture independent?  Perhaps a small
> enough case to ignore.  (I would /definitely/ avoid allowing patches
> to apply to more than one OS version -- e.g. no 5.0 and 5.1 patches,
> please -- so perhaps architecture is just another flavour of the
> same issue.)

Currently the only way would be to copy them for every architecture.
Should we be in need for a better way to handle them, we can add it

> Will be able to be used to build patches?

That would be nice but is not currently the case.

> > The patch index is then amended with an OpenSSL s/mime inline text
> > signature executed with the patch signing key.
> What suffix will this file have?

It is called patchlist without a suffix.

> Are end of line conversions a problem? (I think so.)

Shouldn't be. My parser is treating both \r and \n as whitespaces.

> What character set will these files use -- UTF-8?

Ideally we would use US-ASCII ;-) But yes, if required, UTF-8 is
probably the only choice.

> Good luck.  Patching is a nightmare.

We want to make it as easy as possible.


Attachment: pgpyKh2NN5BQh.pgp
Description: PGP signature

Home | Main Index | Thread Index | Old Index