delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2000/06/19/18:30:11

From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: gmp Attention: Eli Z
Date: Mon, 19 Jun 2000 22:49:48 +0100
Organization: Customer of Planet Online
Lines: 106
Message-ID: <394E957C.F2A08F35@phekda.freeserve.co.uk>
References: <Pine DOT SUN DOT 3 DOT 91 DOT 1000619175818 DOT 27216b-100000 AT is>
NNTP-Posting-Host: modem-51.indium.dialup.pol.co.uk
Mime-Version: 1.0
X-Trace: news7.svr.pol.co.uk 961453131 2366 62.136.40.51 (19 Jun 2000 22:18:51 GMT)
NNTP-Posting-Date: 19 Jun 2000 22:18:51 GMT
X-Complaints-To: abuse AT theplanet DOT net
X-Mailer: Mozilla 4.51 [en] (X11; I; Linux 2.2.14 i586)
X-Accept-Language: de,fr
CC: Zippo Workers <zippo-workers AT egroups DOT com>
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> Prashant TR wrote:
> >
> > Eli Zaretskii wrote:
> >
> > > But only if package maintainers put the appropriate *.dsm files into
> > > the distributions.  From my experience, crafting a good .dsm file is
> > > not a trivial job...
> >
> > Yeah, that's true. It would be nice if there would be some software
> > to create DSMs automatically based on some input.
> 
> But that's just it: I don't believe the DSM files _can_ be created
> automatically.

Agreed. zippo does come with a script that takes some of the hassle out of
creating a DSM (it fills in some of the standard fields). It's on my to-do
list to write a program to help with DSM creation. Ideally this would use
the database of available packages to allow easy selection of dependencies
(*).

(*) Not so easy that it allows people to make packages that require all
the latest packages. That really irritates me about using rpm on Linux - I
seemingly have to upgrade multiple packages just to get a .1 version
increase in something. Anyway, sorry about the rant.

> The ones I wrote required non-trivial reasoning and several changes.
> 
> Here are some items I needed to consider:
> 
>   - 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

There are some rough edges in the dependency-checking code, however. I
hope to fix by rewriting it soon.

FPU emulation is not one thing I had thought about. The DSM specification
has the concept of packages providing certain features - perhaps we need a
feature called "fpu" or "floating-point"? The DSM for the DJGPP
distribution would then have a line like:

provides: floating-point

Packages requiring the FPU would then require floating-point to be
present:

requires: floating-point

This would force the DJGPP base package (djdev) to be installed, to
provide emu387.dxe. Any packages containing emu387.dxe should also have
the provides line in their DSM.

You're probably wondering why you'd require djdev to be installed on a
computer with an FPU. Well, zippo could have code added to detect whether
an FPU is present and then install a virtual DSM describing the processor.
This would be analogous to the way it detects the operating system and
installs a DSM for it, when the package database is first created.

>   - 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. zippo will be able to tell what files have changed since
installation (MD5 hashes are taken on installed files), so altered files
are handled properly (backed up / user prompted / whatever).

It is possible to have two versions of the same package installed, e.g.
foo 1.1 binaries and foo 1.2 binaries could be installed. Packages with
the same name do not clash by default. Using an analogue of groff above,
if these packages foo have different directory structures, then they may
clash. In this case, a DSM directive would have to be added to make them
clash, to prevent them from being installed simultaneously. This issue and
many other issues need to be added to a DSM-writing HOWTO (also on my
to-do list ;) ).

> IMHO if you neglect to address these issues, the DSM files really don't
> serve users as well as they were supposed to.

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.

FYI the zippo home page is here:

http://www.phekda.freeserve.co.uk/richdawe/zippo/

Bye,

-- 
Richard Dawe
[ mailto:richdawe AT bigfoot DOT com | http://www.bigfoot.com/~richdawe/ ]

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019