Message-Id: <200006201953.WAA22400@alpha.netvision.net.il>
Date: Tue, 20 Jun 2000 22:55:20 +0200
X-Mailer: Emacs 20.6 (via feedmail 8.1.emacs20_6 I) and Blat ver 1.8.5b
From: "Eli Zaretskii" <eliz AT is DOT elta DOT co DOT il>
To: lauras AT softhome DOT net
CC: zippo-workers AT egroups DOT com, djgpp AT delorie DOT com, rich AT phekda DOT freeserve DOT co DOT uk
In-reply-to: <394FBDB7.D32205BA@softhome.net> (message from Laurynas Biveinis
	on Tue, 20 Jun 2000 20:53:43 +0200)
Subject: Re: [zippo-workers] Re: gmp Attention: Eli Z
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000619175818 DOT 27216b-100000 AT is> <394E957C DOT F2A08F35 AT phekda DOT freeserve DOT co DOT uk> <200006201819 DOT VAA03943 AT alpha DOT netvision DOT net DOT il> <394FBDB7 DOT D32205BA AT softhome DOT net>
Reply-To: djgpp AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

> Date: Tue, 20 Jun 2000 20:53:43 +0200
> From: Laurynas Biveinis <lauras AT softhome DOT net>
>
> > It is not clear to me that this will not backfire.  One problem is
> > that *.mft files name directories as well as files.  You cannot safely
> > remove directories (because other packages might share them), but if
> > you leave them alone, you might end up with empty directories
> > cluttering the installation.
> 
> Would removing only empty directories work better?

Probably, but to be sure, you would have to remember all the
directories you saw, then come back to them later when all the files
are already removed, and only then remove the empty directories, in a
bottom-up fashion.  That's because a directory that is not empty when
you see its name may become empty later, when files in it are removed.

> > A similar situation is when installing one package requires removal of
> > a file from another package.  An example is the lib/specs file
> > inconjunction with GCC installation.
> 
> This kind of problem should, ideally, be solved in some
> other way, like deciding which one package should own the file.
> Of course, it may be not trivial.

It's not always possible to make this decision.  And, of course, when
old decisions are changed, like in the case of lib/specs, you don't
have a choice but to put DSM to some real work.  After all, that's
what the DSM was invented for, right?