Subject: Re: DEINSTALL scripts for daemon packages
To: NetBSD Package Tech <tech-pkg@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: tech-pkg
Date: 05/24/2001 21:33:38
[ On Friday, May 25, 2001 at 00:55:52 (+0200), Thomas Klausner wrote: ]
> Subject: Re: DEINSTALL scripts for daemon packages
>
> Since you seem to express your feelings about it, let me express mine:
> 1) Nobody needed it -- we had over 1500 (lots more, but I'm not
> exactly sure on the number, so let's just say 1500) packages in pkgsrc
> when I removed it, and the _four_ uses that were made of it where
> easily replaced by some code in INSTALL (one was actually just a
> MESSAGE in disguise). And I haven't run over a package where I would
> have liked to have it, and I have looked at a lot of packages, believe
> me.

Nobody needed `require' files because few people use binary packages.

However if you use *only* binary packages (as I have in some instances
for several years now), you'll find that `require' scripts make an
enormous positive difference, especially through transitions and
upgrades!

Similarly it is only them that can cleanly and elegantly solve the
very problems posed in this thread (at least given the current
implementation of pkg_delete, anyway).

> 2) 'undocumented policy': I didn't have to remove much text that
> explained what to use REQ for. [Perhaps that's a reason that not many
> packages used it, if you want. On the other hand, it doesn't seem
> anybody else has been missing REQs.]

The documentation to use `require' files is still plainly in the pkg*
manual pages, and pkgsrc/Packages.txt makes no mention of avoiding their
use (even though it goes to lengths to suggest avoiding other things).

> 3) It adds overhead, and INSTALL can be easily used for the same -- no
> need to differentiate.

No, `install' scripts have different semanitcs.

They can paper over many of the needs for `require' scripts (courtesy
only the PRE-INSTALL action, if their author is very careful and
understands fully what's going on), but they cannot "be easily used for
the same".

However the `deinstall' script cannot even approach being able to paper
over a missing `require' script since it has no PRE-DEINSTALL action,
only a POST-DEINSTALL action.  (thus the nature of this very thread!)

> Perhaps I'm missing something, but what's the advantage of splitting
> in a 'check' and 'modify' part? Like, can you point to packages where
> it really would help?

I'm probably not the best person to further here, except perhaps by
example.  You'll find several of my PRs in the pkg category which
contain `require' scripts.  I'm not sure they're all ideal
implementations but they may help explain better how I see these things
being used.  Actually I've almost finished "upgrading" my changes for
www/squid and hoped to send-pr them again soon.  I had some good changes
for postgresql and cyrus-imapd once upon a time too that I should
probably re-visit and bring forward to the modern pkgsrc.

> If a necessary thing, if missing, can be done automatically, it should
> be, and if it can't, it doesn't matter if INSTALL tells you so or if
> REQ does, does it?

Well, not as a user, I guess, though it's much easier to understand if
you go to look into the implementation.  Certainly for the implementer
it is much easier to keep things straight with them.  PRE-INSTALL (and
POST-DEINSTALL) are useful separately in many cases from performing
requirements checks.
 
> So, in summary: Just use (DE)INSTALL instead.

You cannot use DEINSTALL.  It happens in the wrong order to be of any
use in solving this (critical IMHO) problem.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>