Mail Archives: djgpp/2000/06/20/14:20:23
> From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
> Newsgroups: comp.os.msdos.djgpp
> Date: Mon, 19 Jun 2000 22:49:48 +0100
>
> > - What other programs/packages are related to this one (for the
> > depends-on and requires clauses)? For example, Make depends on Bash
> > for running Unix Makefile's, on emu387.dxe on FPU-less machines, and
> > on djtzn for files received from remote machines (e.g., in an
> > archive).
>
> These things should be easy to add right now, using simple package
> dependencies, e.g.:
>
> depends-on: bash >= 2.03
The problem is not depends-on, the problem is to decide what to write
on the right-hand side of the colon ;-).
For example, if compilation of one specific package requires support
of /dev/env feature, you need to require djdev v2.03 or later. The
challenge here is to notice that /dev/env is required, and to find the
first version of DJGPP that supported it.
> > - 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.
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.
So some, admittedly rare, cases might require ``manual'' removal of
some files with explicit commands inside the DSM.
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 ;-).
> I recently saw a comparison of package managers on Linuxcare. The thing
> they seemed to miss was that ease-of-use of packages depends both on the
> manager and the packages themselves.
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.
- Raw text -