Message-ID: <394FBDB7.D32205BA@softhome.net>
Date: Tue, 20 Jun 2000 20:53:43 +0200
From: Laurynas Biveinis <lauras AT softhome DOT net>
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: lt,en
MIME-Version: 1.0
To: zippo-workers AT egroups DOT com
CC: djgpp AT delorie DOT com, Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>,
        Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
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>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Eli Zaretskii wrote:
> > >   - Do we need to remove files from old releases, to prevent problems?
> > >     For example, Groff 1.10 had a slightly different directory structure
> > >     than v1.15 and later; Groff 1.16 removes one of the programs and
> > >     renames several man pages or moves them to different subdirectories.
> >
> > We had a discussion on the zippo-workers list some time ago about what
> > should happen when upgrading a package. IIRC the consensus was that the
> > best way to upgrade was to remove the old version and then install the new
> > version.
> 
> 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?

> 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.

> Note that my only reason for talking about this is to show that
> providing a good DSM is not a trivial job.  I don't want to say that
> zippo is not useful, but rather to point out that it needs non-trivial
> help from a human ;-).

That's the point.

> With all due respect to Linux, I don't think we have too much to learn
> from them in this aspect.  You might wish to count the number of
> messages on, e.g., gnu.emacs.help from people bogged down in RPMs to
> the degree that they cannot get a workable Emacs installation.

There are tools on Linux which might be considered as an example
for us - e.g. APT on Debian has left good impression for me. It tries 
hard to solve dependencies automatically. This is not (and it couldn't be) 
100% reliable, but in many cases it 'just works'. For example, user wants 
to install Emacs with X Window suppport, but he hasn't installed the later. 
APT will automatically fetch all x window infrastructure, X server, 
libraries, and emacs from FTP and install it. Of course, it won't automagically 
fetch the correct X server for user's video card, but it's certainly better
than
rpm -i emacs-20_05-i386-blah-blah.rpm
[50 unresolved dependencies snipped]

[Rich, maybe it's a good idea to remove 'Reply-To' from zippo-workers?
Because the list is open for non-subscribers, it's the best way to
ensure that 'Reply-All' function in mailer will DTRT. I had somewhere
an URL to article 'Why Reply-To is A Bad Idea', if you're interested.]

Laurynas