Salut,
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,
right?
> 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
later.
> Will build.sh 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.
Tonnerre
Attachment:
pgpyKh2NN5BQh.pgp
Description: PGP signature