Re^4: Debian Metadata Proposal -- draft rev.1.4
Am 06.07.98 schrieb Marcus.Brinkmann # ruhr-uni-bochum.de ...
Moin Marcus!
MB> You don't need to organize it better. People will work from examples
MB> anyway. I never really read the standard how to write a menu file. I just
Well, I think such a standard is very important for the maintainers. I#ve
got for example problems with debian/control several times, because
there#s no such standard.
MB> Marco, I really hate the howto section in the DDH. I don't hate the idea
I can#t understand this. As maintainer of several howto packages I think
we should have such a section.
MB> to access howtos in a single section, but I hate the orthogonality of DDH
MB> and Document Type. I think the Type: field is the correct solution for
MB> this problem. I hoped you would recognize this and would be happy that
MB> this is adressed properly. In some way, it was requested by you.
I think the Type tag is very inconsistent. And where#s the difference for
the user?
MB> > > or selfhtml
MB> > Never heard of it. References?
MB> It is a HTML tutorial in german language. I don't have it around, so I
MB> can't check what it says about Dublin Core.
It#s part of Debian 2.0. Really a great document for Germans :). As I read
the Dublin Core Homepage Dublin Core will never be a standard. The team is
working on RDF (XML based), see www.w3.org.
MB> I don't think Type is trivial, btw. I think it is a *mayor* improvement,
MB> because it allows flexible data access, much more flexible than
MB> implementing howto and faq sections in the DDH.
And how would you describe all other documents with type? Using type will
produce a lot of work for the package maintainers without any improvements
for the users.
MB> I too can't understand why Marco objects against an optional field. Marco,
MB> you don't need to implement it in dhelp. What exactly is your technical
MB> argument?
That#s right, I#ll not use it. An argument is space on the local disc. Why
should we add the same information several times to the hard disc? I think
we should make docreg as simple as possible. This will help the
maintainers understanding our standard.
And if we think some times later, that we need such a tag, it#s no problem
to add it.
MB> I disagree. Spreading hidden files around /usr/doc and /usr/share/doc is
MB> flawed and contradictionary to the unix way of doing this. Take a look at
Interesting. Could you tell, why the apache team has added more support
for .htaccess files in version 1.3? For example the latest version allows
relative paths to the .htaccess file for the password.
MB> the menu files, they are stored centralized as well.
menu is not a Linux/Unix standard. Have a look at dwww or dhelp :).
MB> One single directory for all doc-reg files is ideal. I can't see any
No, as I#ve showed several times, one directory has got a lot of
disadvantages.
MB> 1) Hidden files (dot-files), this shows that this is the wrong location
MB> for them (you wouldn't expect them to be there).
?
MB> 2) What about files that don't refer to a file under /usr/doc, for example
They#re not allowed, because other directories can#t accessed using the
httpd (see webstandard 3.0).
MB> links in the www?
? Where#s the problem? Every program has got a directory in /usr/doc, this
is part of the policy. Of course URL are allowed.
MB> So we need a /usr/share/doc-base/whatever/docreg/
MB> directory anyway. Why not stroing all files there, then?
We don#t need it.
MB> 3) Accessing a single directory is faster than accessing all directories
MB> in /usr/doc. (Try "time ls /usr/doc/*/copyright" on your system.)
But the system will only access these files one time (during installation
of a package). That#s one reason for using a database.
And your argument is not true in all cases. Try to list a directory of a
large news server. The Linux fs is known to be very slow if you store a
lot of files in one directory.
To get the worst case of my solution, please try option -r of dhelp. This
scans the who /usr/doc tree for .dhelp files.
In real world there#s no speed difference.
MB> Marco, could you please summarize your technical objections agains a
MB> common directory for all files?
1.) With your solution you can only support one subdir (/usr/doc).
But we should offer support for every location (for example
/usr/local/doc).
2.) With your solution we will have a problem to move from
/usr/doc and /usr/share/doc, see (1).
3.) Commercial programs my include docreg files under /opt, see (1).
4.) Relative links are always better, html itself uses in most cases
relative links! Or read the link chapter in the policy.
5.) If a package maintainer has to move a doc directory to another
directory he don#t need to change the docreg file! He moves only
the docreg file to the new location:
/usr/doc/<foo>/ -> /usr/doc/<foo>/html
He has only to change one line in rules:
cp docreg usr/doc/<foo>
to
cp docreg usr/doc/<foo>/html
6.) Upstream maintainers could deliver docreg files. It#s not a problem
to which location the distributors will move the documents.
7.) You can include docreg files to tar archives (they use relative
paths). Example: binary distributions, commercial software.
MB> I don't see any problems here. A relative URL should be checked against
MB> file://localhost/usr/doc/ and file://localhost/usr/share/doc in the
MB> transition period.
Speed :).
cu, Marco
--
Uni: Budde@tu-harburg.de Fido: 2:240/5202.15
Mailbox: mbudde@hqsys.antar.com http://www.tu-harburg.de/~semb2204/
--
To UNSUBSCRIBE, email to debian-doc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: