Re: Playing with the spec
>>"Jochem" == Jochem Huhmann <joh@gmx.net> writes:
Jochem> [Mailed and posted to local.lsb.spec]
Jochem> * Manoj Srivastava <srivasta@debian.org> wrote:
>> Could someone explain the rationale of embedding version
>> numbers in the directory structure, hance having the directory
>> structure change with each package upgrade, rather than having things
>> like /usr/share/sgml/jade-1.2.1/?
Jochem> You don't really want to replace a DTD or such with a newer
Jochem> one, you will still need them for applications that rely on
Jochem> them. "Upgrading" means *adding* new stuff here, not
Jochem> replacing older with newer versions. Therefore there have to
Jochem> be version numbers in the names.
I was not talking of replacing the older versions of the DTD
(yes, that _would_ be horribly broken). However, you do *not* need
package names, and worse, verion numbers cluttering up the archive
structure to achieve that. I posit that embedding package names and
versions numbers shall lead to a directory structure that may grow
untenable in the future, given the potential for rapid explasion of
packages and DTD's as XML gets wider acceptance.
On my machine, there exists a single <path to sgml/dtd/
directory (subdirectories are permitted therein). The HTML DTD's are
all there, and we do not replace the older ones when neew version
come out: the sgml.catalog reads (in part):
PUBLIC "-//W3C//DTD HTML 4.01//EN" dtd/html-4.01s.dtd
PUBLIC "-//W3C//DTD HTML 4.0//EN" dtd/html-4.0s.dtd
PUBLIC "-//W3C//DTD HTML Experimental 970421//EN" dtd/html-970421.dtd
PUBLIC "-//W3C//DTD HTML 3.2S Draft//EN" dtd/html-970421.dtd
PUBLIC "-//W3C//DTD HTML 3.2//EN" dtd/html-3.2.dtd
PUBLIC "-//IETF//DTD HTML//EN//3.0" dtd/html-3.dtd
PUBLIC "-//IETF//DTD HTML 2.1E//EN" dtd/html-2.1e.dtd
PUBLIC "-//IETF//DTD HTML 2.0//EN" dtd/html.dtd
PUBLIC "-//IETF//DTD HTML Level 1//EN" dtd/html-1.dtd
PUBLIC "-//IETF//DTD HTML Level 0//EN" dtd/html-0.dtd
Similar thing can be done with docbook (I just chose HTML
for brevity of the example).
Jochem> We are thinking about a useful structure for this right now. One
Jochem> possibility would be to package this like that:
Jochem> /usr/share/sgml/
Jochem> docbook-3.1/
Jochem> dtd/
Jochem> entities/
Jochem> style-sheets/
Jochem> images/
Jochem> If now KDE wants to install it's own package for documentation
Jochem> converting, it could plug it in as this:
Jochem> /usr/share/sgml/
Jochem> kde-1.2/
Jochem> dtd/
Jochem> entities/
Jochem> style-sheets/
Jochem> images/
Jochem> This is just an idea and may be way too simple.
Ugh. Even if we were just talking about docbook, this seems
inverted, and non UNIXy. (This like /usr/emacs/bin,
/usr/yacc/bin. /usr/vi/bin, etc.).But as distribution person, we
shall have scores of packages providing their own DTD, and this
embedding of package name and version number in the file structure is
ugly. And makes finding anything, unless you know the package name
and version, harder. It also makes it hard to write convenience
scripts; the script needs to be able to parse the catalog to know
where the DTD's are.
I think we can get the best of both word by specifying a
single set of directories, and letting packages achive that by
symlinking from wherever they wish into /usr/share/sgml/{dtd,entities,...}
I find this structure easier to navigate (I know off hand
where stylesheets are, on my machine, and it is far easier for the
user to browse them).
Espescially since there has not been a good reason to do so: I
would prefer capturing the version information in the file name,
rather than the directory structure, based on teh same arguments that
we have a consolidate bin directory rather than a plethora of bin
directories
I would even be willing to go to allowing large apllications
to have their own subdirectory under /usr/share/sgml/dtd/, somewhat
like the dispensation given to X11 (/usr/bin/X11/ directories, for
example).
manoj
--
The meeting of two personalities is like the contact of two chemical
substances: if there is any reaction, both are transformed. Carl Jung
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: