On Sat, 8 Jun 2002, Julio Merino wrote:

> This is done, most times, with something like this:
> include/package/version/*. Well, old (v1) packages have in their PLIST:
> @dirrm include/package/1
> @dirrm include/package
>
> And new packages have:
> @dirrm include/package/2
> @dirrm include/package
>
> But here is the problem. If you have both packages installed and you ever
> want to delete some of them, you will see an annoying message saying that
> include/package can't be removed. This is non-fatal, you know, but it is
> annoying to see the warning every time (and it makes the impression to the
> end-user that the package is wrong).

I see a lot of those warning when updating packages out-of-sequence,
and I noted that as a problem in the TODO for pkg_hack.

> How could we handle this to avoid the warnings? Maybe a... @commondirrm?

It strikes me that an elegant solution would for the package tools to
create a database -- one that permitted duplicate keys -- so you could
tell which packages owned any particular directory, and only delete
that directory after the last owning package is deleted.

The usual fix is to do "@rmdir %D/include/package || true" instead of
"@rmdir include/package" in each package, everywhere it comes up.
"pkglint" will complain about that. The real problem with that, is
that the maintainer has to know, somehow, that that directory is used
by another package.

Another possibility would be for "pkg_delete" to just shut up if a
directory it attempts to delete because of "@dirrm" isn't empty. The
maintainer has other ways of verifying the PLIST, and the user
probably doesn't care.

Frederick