On Fri, 10 Jan 2003, Frank Cusack wrote:

> On Thu, Jan 09, 2003 at 12:20:32PM -0800, Jeremy C. Reed wrote:
> > In my particular case, I could have some .mk definition to set
> > DEPENDS+= to a few packages to apply for all packages. That way deleting
> > sh-utils (for example) couldn't be removed until all other packages were
> > removed first -- which would become impossible.
> >
> > So then how to update sh-utils in this case?
>
> make replace?

The replace target does a "deinstall" (after tarring up already installed
package and moving the +REQUIRED_BY file). So these essential tools will
be gone momentarily (which is too long). And then the make will fail,
because missing echo(1).

Another example would be a bmake (or nbmake package): if it was
deinstalled, then the recursive makes wouldn't work.

Other examples could be tar, gzip, bzip2 (tools or libraries).

Anyways, my main concern is with the binary packages used by
unknowledgable end-users. They must not make it easy to fail. The best
example is tar. If it is removed, then pkg_add won't work.

Once pkg_install is a real package, then tar (gtar, pax, star) can be a
dependency. But need a clean way to allow updating it in place without
removing it. -f works to overwrite, but not clean.

-u does a pkg_delete (after moving +REQUIRED_BY file) -- so not good,
because tar would be gone and can't install again.

Or maybe the package could be (is?) extracted (untarred) first to the temp
directory before doing the pkg_delete. Then that would be okay.

On Fri, 10 Jan 2003, Alistair Crooks wrote:

> Not sure about appriciation, but I've been wondering for a while now
> if we shouldn't add some kind of analogy of an immutable flag to
> packages, which would prevent pkg_delete from deleting a package if it
> was present.  This might be in the form of yet another variable that
> gets sprinkled around package Makefiles, and stored in the package
> metadata in ${PKG_DBDIR}, or maybe just a simple chmod in/on the

> Anyway, "we're working on it".

Excellent! Please let us know, so we can help test (or code).

Thank you for your comments.

   Jeremy C. Reed
   http://bsd.reedmedia.net/