Mail Archives: djgpp-workers/2000/04/09/08:14:48
Hello.
Eli Zaretskii wrote:
> I looked through the DSMs, made a DSM file for Make 3.79, and I have
> several comments about the DSM spec as a side-effect.
Thanks for your useful comments Eli.
> 1) It is not clear how to put more than a single value into a
> directive. For example, there might be more than one author of a
> given package for the `author', `author-email' and other related
> directives. Similarly, `depends-on' and `requires' might need more
> than a single value. How should one go about doing this?
This is perhaps a result of the fact the DSM specification doesn't really
have a full formal syntax definition (in BNF or whatever).
The 'author' and 'author-email' fields are only intended to take the
details of one author. Similarly for 'depends-on' and 'requires' and the
other dependency directives. For multiple values, you need multiple
directives.
I guess the problem with multiple 'author*' directives for each author is
how to associate an e-mail address with an author's name. This would be
done by the order in which they occur in the DSM.
> 2) The fine difference between `depends-on' and `requires' is not
> clear, because ``functions properly'' and ``functionality may be
> impaired'' are ambiguous. If the intent is that `requires' is any
> requirements without which the package will not work at all, then
> the spec should say so.
Yes, 'requires' has the meaning you suggest.
[snip]
> For example, diff's -l switch needs pr.exe, several of Emacs commands
> won't work without ispell, man, Grep, diff, and other programs, etc.
> All these aren't mentioned, so it is hard to understand the intent of
> `depends-on'.
One limitation of the DSM spec is that you can't specify dependencies on a
file within a package - you have to put a dependency for the entire
package. IMHO I don't think this is a problem.
> 3) It seems like the spec is heavily slated towards installing a
> package, because some of the directives required for uninstalling
> are missing. For example, a script and/or command to run when
> uninstalling would be a good idea (e.g., to run install-info to
> remove the entry from info/DIR).
I think you may have missed these directives in the DSM specification,
e.g. for pre-uninstall-script see:
http://www.phekda.freeserve.co.uk/richdawe/zippo/dsm2.htm#IDX77
It's quite possible the specification is slanted towards installs, because
that's all that currently works with zippo. I hope to code uninstalls soon
(next month or so).
> 4) I think we need a `current-maintainer' directive and the associated
> `current-maintainer-email', because the current maintainer might be
> someone different from the original author. This is the case with
> many GNU packages.
Yes, this would be a good idea. Do we need the prefix 'current-' though?
Wouldn't 'maintainer' and 'maintainer-email' do? For completeness I think
we should have 'maintainer-im', 'maintainer-web-site' and
'maintainer-ftp-site' too.
> 5) To have a useful partition using the `group' directive, we need a
> list of standard groups. We also need to address the possibility
> that some packages would want to belong to more than a single
> group.
Yes, standard groups would be a good idea. This hasn't really been
discussed yet. Laurynas has written a group DSM for gnutools &
Borland-like development environment.
It should be possible for packages to belong to multiple groups. I don't
think there's anything in the DSM specification or the implementation in
zippo that will preclude that.
> 6) It is not clear what do we ned to put under `mailing-list',
> `newsgroup', and related directives. Are these for reporting
> problems in DJGPP ports, general discussions about the package, or
> something else, like discussing the package internals?
The intent was for them to general discussion lists/groups.
> In general, any given package will typically have several relevant
> mailing lists and/or news groups, in addition to
> comp.os.msdos.djgpp where they all can be discussed. So we need
> clear guidelines about what to put there.
I think that the people who are interested in internals will go to the
home page and find out from there which mailing lists exist. The general
discussion list or "user" list is probably the most appropriate one for
'mailing-list'.
I agree we need some guidelines here.
> Or perhaps we need to have several different directives for the
> different types of forums.
We could do, but then how many different types do we need? I think three
at most: announcements, general, development. Any more than that and I
think we are just adding clutter.
> 7) Perhaps the installer and uninstaller should automatically run
> install-info with the appropriate arguments (these arguments are
> pretty standard). This way, people won't need to put these
> commands into the DSM files, which is error-prone.
Again, thanks for your comments. I will try to make the DSM spec more
explicit.
Bye,
--
Richard Dawe
richdawe AT bigfoot DOT com ICQ 47595498 http://www.bigfoot.com/~richdawe/
- Raw text -