Re: make replace

[Marc Espie <espie%nerim.net@localhost>]

On Fri, Jul 09, 2010 at 01:48:12AM +0200, Joerg Sonnenberger wrote:
> On Wed, Jul 07, 2010 at 06:59:02PM +0200, Dieter Baron wrote:
> >   I think the package tools should be smarter in handling installation
> > of dependencies and updates, figuring out beforehand if the desired
> > result can be accomplished, rather than installing a bunch of packages
> > and then erroring out because a conflict arose.  These kind of
> > operations have to consider the installed package tree as a whole (or
> > at least a subtree thereof), and thus have a legitmate desire for
> > consistency constraints on the trees they have to operate on.
> 
> I am not sure how much of that can really be done for source builds.
> For binary package handling, it is the goal (at least for a frontend) to
> bail out before doing anything. The exception is a failing +INSTALL
> script, that isn't easy to predict.

There is a way around that (and a goal): remove INSTALL scripts.
It's not always feasible, but there are a lot of packages (and maintainers)
that believe they are "special", and so they need INSTALL scripts, they need
specific support (we have the same issue in OpenBSD).

The very long road is:
- identify the legitimate operations that INSTALL scripts will do, and provide
alternate global mechanisms that will do the same thing (to wit: we replaced
all user/group creation with packing-list annotations).
- move as much operations as possible to the packaging-stage (especially with
USE_DESTDIR).
- rework a lot of packages so that they're no longer special. There is a
*huge* amount of trivialities that can be totally removed.

In the end, we end up with maybe ten percent of install operations left...
and we actually removed INSTALL/DEINSTALL (@exec/@unexec has more precise 
semantics, and does not need to remember rules as to when it's called,
what to pass it, etc). Plus, we added @exec-add/@exec-update (and similarly
to unexec) to distinguish between package addition and package updates:
that way we run half the number of gnome database update operations during
an update, and we can watch much more carefully over 
@exec-update/@unexec-update (since those are ways more dangerous than
simple add/delete).

Of course, telling people that their special packages are only "special"
in the same sense that you talk about "special children" (e.g., retarded)
will make some teeth gnash.  In OpenBSD land, we don't really care, we don't
have to be PC. ;-)