Re: Introducing the patchadd binary patch toolchain

[Giles Lean <giles.lean%pobox.com@localhost>]

Tonnerre LOMBARD <tonnerre%netbsd.ch@localhost> wrote:

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

Yes -- no tools or people would be able to tell what the real
dependencies are.  And yes, such situations should not happen
... but in the real world, errors are made.

> > Are end of line conversions a problem? (I think so.)
> 
> Shouldn't be. My parser is treating both \r and \n as whitespaces.

I meant are line endings a problem with respect to the signing.

> > Good luck.  Patching is a nightmare.
> 
> We want to make it as easy as possible.

Yes, and it might still be a nightmare. :-)

The nature of the problem makes it difficult.  There are at least
three different groups of people all with valid but somewhat
conflicting wishes who work on patches (at least in the commercial
space):

o users (naturally)

  For larger sites trying to have a 'standard' set (usually, sets)
  of patches and managing the updates of such sets (both when to
  change what patches are in the set, and when to apply that set to
  production machines) can be a major endeavour

o developers

  Developers of course want to fix known problems, and sometimes
  -- although doing so via a patch is usually unwise -- add new
  features.

  The problem developers have is they're usually running something
  like -current, and customers will be a whole OS release or two
  back.  Testing real world combinations of what users are running
  (applications and patches) is hard.

  Once users are choosing which patches to install (i.e. as soon as
  "install everything" is impractical) it's hard even to duplicate
  one user's environment when that is necessary.

o support people

  Get enough patches and just navigating them is hard.  Been there,
  done that.

Regarding something I didn't think to ask in my first response:
are there any places during the patch installation where scripts
are run?

Being able to run scripts before installation (e.g. to check if
the software being patched is installed) or after installation
(e.g. to update a configuration file) is very convenient and
"Unix-like" but it makes static analysis or which patches touch
which files very difficult, probably impossible in the general case.

Of course the problem remains: if a configuration file must be
changed for a patch to work correctly, whether the patch installation
changes it, some rc.d script changes it, or the user changes it, it
still gets changed in conjunction with the patch installation.

There are many reasons why I've said (only half-jokingly) that patches
are a nightmare.  They may well be worth doing, but they do open the
doors to a lot of complexity.

Cheers,

Giles