Quoting Adam Di Carlo <[EMAIL PROTECTED]>: > > 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 <[EMAIL PROTECTED]> Debian XML/SGML <[EMAIL PROTECTED]> Home Page: <http://dulug.duke.edu/~mark/> GPG fp: 50DF A22D 5119 3485 E9E4 89B2 BCBC B2C8 2BE2 FE81 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
