[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: question about placements in /usr/share/xml



Quoting Adam Di Carlo <aph@debian.org>:

> 
> I have some questions about where to play stuff in /usr/share/xml as I
> move the sgml-data package over to comply with the XML draft policy.
> These are questions for Mark in particular.
> 
> Here's what I have so far:
> 
> /usr/share/xml/declaration:
>   big5xml.decl  xml.dcl  xml1n.dcl
> 
> /usr/share/xml/entities:
>   xml-iso-entities-8879.1986/
> 
> /usr/share/xml/qaml:
>   catalog  catalog.xml   qaml-xml.dtd
>   old location: /usr/share/sgml/dtd/qaml-xml.dtd
> 
> /usr/share/xml/svg:
>   catalog  catalog.xml   svg10.dtd  svg11.dtd
>   old location: /usr/share/sgml/dtd/svg10.dtd
> 
> I've opted to put SVG and QAML in their own directories.  Putting them
> under /usr/share/xml/schema seems to conflict with "3.1.3. Local
> Catalogs: /usr/share/xml/.../package-dir/catalog.xml".  I would have
> to name the catalogs qaml-xml.catalog or something.  

> Note: this feels like a flaw in XML policy.

How so? I'd be happy to make a change if I understood your point a little better. 

> Does this seem ok?  correct?

Yep, seems OK to me. Somewhere in the policy it states that any package that has
its own catalog _must_ install in its own directory. Otherwise you get
name-clashing with the local catalogs, as you point out.

I think you could go either way, putting them right in /usr/share/xml or in
/usr/share/xml/schema. But you'd still have to give them their own
subdirectories because of the catalog-clashing problem.

FWIW, I noticed that FHS wants mathml to reside in /usr/share/xml/mathml, which
is not where I put it. Oops. Another fix.

> FYI, of course I'm going to create symlinks from the old locations
> under /usr/share/sgml for backwards-compatability.

Good. For some reason, dh_link isn't creating the links for me. They show up in
the package build area, but not when installing the package. What's created is
an empty directory. Not so useful:)

There is an exception: for some packages, if I create the directory (via
<package>.dirs) where the link is to reside everything seems to work. I've still
got a couple docbook-* packages that don't provide the symlink that I need to
fix by editing the postinst manually. Have you had any problems of this sort?
Any ideas why it might be happening to me??

BTW, I got a bug report against docbook-xsl because of a missing symlink. The
maintainer's package wouldn't build properly without it. My point: we definitely
need the symlinks.

As always, any feedback on the policy doc is welcomed. Your comments have
already lead to some major revisions. Cool.

HTH,

Mark

-- 
_____________________________________
Mark Johnson        <mark@duke.edu>
Debian XML/SGML     <mrj@debian.org>
Home Page:          <http://dulug.duke.edu/~mark/>
GPG fp: 50DF A22D 5119 3485 E9E4  89B2 BCBC B2C8 2BE2 FE81



Reply to: