[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Introducing the patchadd binary patch toolchain
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,
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
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
Developers of course want to fix known problems, and sometimes
-- although doing so via a patch is usually unwise -- add new
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,
Regarding something I didn't think to ask in my first response:
are there any places during the patch installation where scripts
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.
Main Index |
Thread Index |