doc-base control file madness

1999-01-21 Thread Ben Gertzfield
I've recently looked into the doc-base control file format. It seems
pretty sane, except I realized since it does not provide for any
macro expansion, I will have to edit the 8 or 9 doc control files
libgtk1.1.13-doc (and 1.1.14, and 1.1.15, ad nauseum) provides
EVERY SINGLE TIME there is a new release.

Yuck.

Is there any way doc-base can provide some kind of macro expansion,
so I don't have to edit:

/usr/doc/libgtk1.1.13-doc/gtk-faq.html/
...

every time I have a new package, instead, doing something like

VERSION=1.1.13

/usr/doc/libgtk${VERSION}-doc/gtk-faq.html/
...

? This would be much nicer.

Ben

-- 
Brought to you by the letters D and W and the number 8.
Yasashisani tsutsumaretanara, kitto.. meni utsuru..
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.



Re: doc-base control file madness

1999-01-21 Thread Dale Scheetz
On 21 Jan 1999, Ben Gertzfield wrote:

 I've recently looked into the doc-base control file format. It seems
 pretty sane, except I realized since it does not provide for any
 macro expansion, I will have to edit the 8 or 9 doc control files
 libgtk1.1.13-doc (and 1.1.14, and 1.1.15, ad nauseum) provides
 EVERY SINGLE TIME there is a new release.

Can't you use something like m4 as a pre-processor and do macro expansion
that way?

Luck,

Dwarf
--
_-_-_-_-_-   Author of The Debian Linux User's Guide  _-_-_-_-_-_-

aka   Dale Scheetz   Phone:   1 (850) 656-9769
  Flexible Software  11000 McCrackin Road
  e-mail:  [EMAIL PROTECTED] Tallahassee, FL  32308

_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-



Re: doc-base control file madness

1999-01-21 Thread Ben Gertzfield
 Dale == Dale Scheetz [EMAIL PROTECTED] writes:

Ben I've recently looked into the doc-base control file
Ben format. It seems pretty sane, except I realized since it does
Ben not provide for any macro expansion, I will have to edit the
Ben 8 or 9 doc control files libgtk1.1.13-doc (and 1.1.14, and
Ben 1.1.15, ad nauseum) provides EVERY SINGLE TIME there is a new
Ben release.

Dale Can't you use something like m4 as a pre-processor and do
Dale macro expansion that way?

That would work, but it would be nice if it were built into the
control file language. Many people will need this functionality in the
future.

Ben

-- 
Brought to you by the letters Z and H and the number 9.
To Perl, or not to Perl, that is the kvetching.
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.



Re: doc-base control file madness

1999-01-21 Thread Joel Klecker
At 08:06 -0800 1999-01-21, Ben Gertzfield wrote:
Is there any way doc-base can provide some kind of macro expansion,
so I don't have to edit:
/usr/doc/libgtk1.1.13-doc/gtk-faq.html/
...
every time I have a new package, instead, doing something like
VERSION=1.1.13
/usr/doc/libgtk${VERSION}-doc/gtk-faq.html/
In glibc I do something (almost exactly) like:
In debian/libc-doc.doc-base.in:

Format: info
Index: @infodir@/libc.info.gz
Files: @infodir@/libc.*
Format: HTML
Index: @docdir@/@[EMAIL PROTECTED]/html/libc_toc.html
Files: @docdir@/@[EMAIL PROTECTED]/html/*.html

Then in debian/rules:

debian/libc-doc.doc-base: debian/libc-doc.doc-base.in
   sed -e '[EMAIL PROTECTED]@%$(glibc)%g' -e '[EMAIL 
PROTECTED]@%$(infodir)%g' \
   -e '[EMAIL PROTECTED]@%$(docdir)%g'  debian/libc-doc.doc-base.in  \
   debian/libc-doc.doc-base
# Paranoia
touch $@

Then I have the target that generates the glibc-doc .deb depend on 
the debian/libc-doc.doc-base rule.

And make of course takes care of making sure debian/libc-doc.doc-base 
is up to date with regard to debian/libc-doc.doc-base.in.
--
Joel Klecker (aka Espy) URL:http://web.espy.org/
URL:mailto:[EMAIL PROTECTED]  URL:mailto:[EMAIL PROTECTED]
Debian GNU/Linux PowerPC -- URL:http://www.debian.org/ports/powerpc/



Re: doc-base control file madness

1999-01-21 Thread Jules Bean
On 21 Jan 1999, Ben Gertzfield wrote:

  Dale == Dale Scheetz [EMAIL PROTECTED] writes:
 
 Ben I've recently looked into the doc-base control file
 Ben format. It seems pretty sane, except I realized since it does
 Ben not provide for any macro expansion, I will have to edit the
 Ben 8 or 9 doc control files libgtk1.1.13-doc (and 1.1.14, and
 Ben 1.1.15, ad nauseum) provides EVERY SINGLE TIME there is a new
 Ben release.
 
 Dale Can't you use something like m4 as a pre-processor and do
 Dale macro expansion that way?
 
 That would work, but it would be nice if it were built into the
 control file language. Many people will need this functionality in the
 future.

Aside: Actually, the important versioning issues raised by libgtk might
need addressing in another way, although I can't think of the Right Way
just now.

ObMacros:

In general, it is IMHO silly to rewrite, yet again, a macro substitution
engine into a special purpose piece of software (doc-base) when we already
have several good, fast macro substituters (cpp, m4) and a framework from
which they can easily be run (debian/rules).

Jules
 
/+---+-\
|  Jelibean aka  | [EMAIL PROTECTED] |  6 Evelyn Rd|
|  Jules aka | [EMAIL PROTECTED]  |  Richmond, Surrey   |
|  Julian Bean   | [EMAIL PROTECTED]|  TW9 2TF *UK*   |
++---+-+
|  War doesn't demonstrate who's right... just who's left. |
|  When privacy is outlawed... only the outlaws have privacy.  |
\--/



Re: doc-base control file madness

1999-01-21 Thread Ben Gertzfield
 Jules == Jules Bean [EMAIL PROTECTED] writes:

Jules In general, it is IMHO silly to rewrite, yet again, a macro
Jules substitution engine into a special purpose piece of
Jules software (doc-base) when we already have several good, fast
Jules macro substituters (cpp, m4) and a framework from which
Jules they can easily be run (debian/rules).

Okay, I guess I have no excuse. I'll just have to learn m4 or use
perl or sed.

Ben

-- 
Brought to you by the letters B and T and the number 16.
Do you wish to see our *surprising toys*? No! Do not!
Debian GNU/Linux maintainer of Gimp and GTK+ -- http://www.debian.org/
I'm on FurryMUCK as Che, and EFNet/Open Projects IRC as Che_Fox.



Re: doc-base control file madness

1999-01-21 Thread Adam Di Carlo

On Thu, 21 Jan 1999 17:18:21 + (GMT), Jules Bean [EMAIL PROTECTED] said:
 On 21 Jan 1999, Ben Gertzfield wrote:
  Dale == Dale Scheetz [EMAIL PROTECTED] writes:
Ben I've recently looked into the doc-base control file format. It
Ben seems pretty sane, except I realized since it does not provide
Ben for any macro expansion, 

Dale Can't you use something like m4 as a pre-processor and do macro
Dale expansion that way?

  That would work, but it would be nice if it were built into the
 control file language. Many people will need this functionality in
 the future.

 In general, it is IMHO silly to rewrite, yet again, a macro
 substitution engine into a special purpose piece of software
 (doc-base) when we already have several good, fast macro
 substituters (cpp, m4) and a framework from which they can easily be
 run (debian/rules).

Utterly agree.  To prove it, I'm going to quote my docreg file which
uses m4:

changequote([, ])dnl
define([common_elements], [Title: Debian Metadata Manual
Subject: debian/policy
Description: This manual contains a guide and a reference to the
  Debian Metadata Project. The Project's purpose, and the purpose of
  this document, is to outline a set of metadata elements, to specify
  an interface for package maintainers use in order to provide
  metadata about resources in their packages, to specify a unified
  subject catalog for categorizing metadata, and to specify an API for
  developers who wish to make use of a system's metadata.
Language: en
Creator: A. P. Harris [EMAIL PROTECTED]
Creator: Marcus Brinkmann [EMAIL PROTECTED]
Date: 1998-06-29
Rights: copyright/GPL
Type: specification])dnl

Identifier: debian-metadata/debian-metadata.sgml
Format: text/sgml
common_elements

Identifier: debian-metadata/debian-metadata.html/index.html
Format: text/html
common_elements

Identifier: debian-metadata/debian-metadata.text
Format: text/plain
common_elements