[csw-maintainers] package hooks (update)

[Ben Walton]

Excerpts from Philip Brown's message of Thu Jul 02 21:03:47 -0400 2009:
> On Thu, Jul 02, 2009 at 08:43:36PM -0400, Ben Walton wrote:
> [http://wiki.opencsw.org/package-hooks]

> no it's not clear enough :) you need to be explicit, and state
> whether or not a "upgrade" hook overlaps install/remove hooks, or whether
> it gets called instead of them.
> You also have to explicitly define the order of calling, if they both
> get run

> [hmm actually, you sort of say this in your examples. but you make
>  some mistakes in your examples :) for example, you mix stating
>   that something is being "installed" vs being "upgraded", in the same
>    sample paragraph]

I'll give you the point, but the error is only in perspective.  If a
user requests CSWfoo to be installed when it already exists, the tool
turns it into an upgrade action (layered semantics).  My wording was
from the point of view of the user request.  I've corrected things to
be from the point of view of the tool, since that's more appropriate
to the document.

> > There is no distinction between batchinstall or batchupgrade if that's
> > what you were asking.  We could note the difference by adding a
> > batchupgrade hook if you think that's worthwhile.  I'm not sure it is,
> > but it wouldn't necessarily hurt either.
> 
> If you think it's neccessary to have a per-package upgrade, i think you
> should provide for a batch upgrade, just for completeness. even if you cant
> think of a use for it now, someone later might, if you provide a hook for
> it.

Ok.  We'll add it.  Since this is (again) a synthetic addition, I'll
define batchupgrade such that if _any_ package is to be upgraded from
an older version, the batchupgrade hook will supersede batchadd (which
I've now named batchinstall to be consistent with per-package names).

> Please note: "purge" is DIFFERENT from "remove".
> It has a long-understood meaning in the debian world, and possibly
> others.

I'm aware of the differences.  Purge was used to avoid a name
collision.  That collision no longer exists and we'll forget about
purge.

> "remove" means "run pkgrm".
> "purge" should mean "run pkgrm, and REMOVE ANY LEFTOVERS" (in other
> words, remove any capability/saved state for a delayed upgrade via
> pkgadd later)

Personally, I think even upgrade is a bit of a stretch, since we're
now layering semantics on top of pkgadd/pkgrm.  It's low hanging fruit
though, since the information is readily available in the tools.
While we have the sampleconf classes that can accomplish purge-ish
behaviour, I don't think it would be good to extend too far beyond the
boundaries of pkgadd/pkgrm.

It's also quite difficult for pkg-get/pkgutil to detect the difference
between remove and purge (as handled by the classes), if we wanted to
synthesize it, since it would have to start snooping around to even
get that info.  Unless someone really thinks purge is important, I
think we should walk away from it.

-Ben
-- 
Ben Walton
Systems Programmer - CHASS
University of Toronto
C:416.407.5610 | W:416.978.4302

GPG Key Id: 8E89F6D2; Key Server: pgp.mit.edu
Contact me to arrange for a CAcert assurance meeting.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20090703/4ff27dda/attachment-0002.asc>