Re: (docbook-tools) Re: Playing with the spec

[Jorge Godoy <godoy@conectiva.com.br>]

On Mon, Mar 06, 2000 at 09:22:34PM -0600, Manoj Srivastava wrote:
> 
>         The package puts it's documentation in /usr/share/doc/foo, and
>  the dtd's and files go into /usr/share/foo (note: No version
>  number). The postinstallation script copies the DTD into
>  /usr/share/sgml/dtd/foo-3.2.dtd; the stylesheets goes into
>  /usr/share/sgml/style/foo-3.2.styles, and teh catalog snippet goes
>  into /etc/sgml/catalog.d/foo-3.2 
> 
>         Next, the post instal script calls update-catalog, and the
>  sgml.catalog is regenerated from all the snippets.
> 
>         On an upgrade, the contents of /usr/share/foo and
>  /usr/share/doc/foo are replaced; but the catalog snippet persist
>  across versions.

How does Debian packages know that they _can't_ remove the DTDs or
stylesheets or the catalog? In RPM I can do such a thing by copying
these files and not declaring them in the package (I'm not a RPM guru
so there may be other ways to do that).  The drawback would be that
when I ask for which files belong this package, these won't be
listed. Another problem is that when I ask which package these files
belong to, there will be no package who onws them. 
It possible to have such implementation, but them will hasve to fix
our packaging tools. They'll have to be addwed a permanent flag so
that some files which belonged to e.g. Foo-3.2 now belongs to Foo-3.3
or Foo-4.0 and were not changed. There'll be also these version
specific files, which might be the same (and then we'll be wasting
disk space) or newer ones and differ only in the version number.   

>         The end result is: 
>  Almost all dtds reside in /usr/share/sgml/dtds,
>  Almost all character sets  reside in /usr/share/sgml/charsets
>  Almost all entities reside in /usr/share/sgml/entities
>  Almost all stylesheets reside in /usr/share/sgml/stylesheet
> 
>         (I say almost all since there is provision in our policy for 
>  things akin to /usr/share/sgml/dtds/Blah, analogous to /usr/bin/X11) 
> 
>         The added advantage of this simplified structure is that
>  simple scripts and humans do not have to go rooting through the
>  catalog to find out where the DTD is, or where the stylesheet lies.

In our suggested structure, there's no need for human intervention
too. The catalog is updated (or not - it's a packager decision) by a
simple script which add the line

CATALOG "/path/to/specific/catalog"

(conformant with OpenCatalog specs) to the main catalog file. The
other files can go anywhere the packager wants but the recommended
place is /usr/share/sgml/application-dir 

>         Also, I, personally, find it convenient to just browse the
>  files in /usr/share/sgml/stylesheets/* while trying to learn by
>  example. 

And how would you know easily what files belong to, lets say, the
famous "play" example (the one used to markup theater pieces and
novels)? 

>         You see, people who create distributions do not need a spec to
>  tell them to keep directories around in order to have a working SGML
>  infrastructure -- indeed, I think the current directory structure is
>  an overspecification that I'd find very hard to interleave into my
>  local policy. 

As with any standard, you can choose to accept it's recommendations or
to ignore them. Accepting will make your product compatible and easier
to work (since people will already know how things are organized in
there and how they do work). Ignoring them will make your product less
compatible with this standard. It doesn't mean, in any occasion, that
your implementation wouldn't work. 

--
Godoy.	<godoy@conectiva.com.br> 

Setor de Publicações
Publishing Department                   Conectiva S.A.