[MPlayer-DOCS] [PATCH] make configure and generated main.xml's more "spec-valid"

[Andrew Savchenko]

On 4 Jan 2007 14:03 Torinthiel wrote:
> On Thu, Jan 04, 2007 at 12:40:45PM +0300, Andrew Savchenko wrote:
> > Hi,
> >
> > On 4 Jan 2007 12:13 Torinthiel wrote:
> > > According to the W3C XML specification, and to the DocBook
> > > guide at http://www.docbook.org/tdg/en/html/docbook.html ,
> > > the system identifier of the DTD should be URI. Now the XML
> > > spec shows simple "hello.dtd" as example, so this is quite
> > > valid, but the DocBook suggests file://path URIs which are
> > > correct local file URIs. The attached patch makes configure
> > > use file:// when appropriate, and also fall back to
> > > internet-available DTD if no local was found, which didn't
> > > cause problem on my box (except for a bit slower testing)
> > > and is IMHO better than hard-coding already tested and
> > > non-existent path.
> >
> > And what if I have no access to internet at compile time or if
> > I don't want to waste my traffic?
>
> Than you install proper local DTDs in some more or less standard
> location and if that won't work you add that path to configure
> and send patch. You should do so anyway.

Local DTD is currently detected in my system. But if it will not 
for some reason? Of if there are some people with no DTDs in 
default path?

Interesting, there are my locations of dtd's:
---
$ locate docbookx.dtd
/usr/share/apps/ksgmltools2/docbook/xml-dtd-4.1.2/docbookx.dtd
/usr/share/apps/ksgmltools2/docbook/xml-dtd-4.2/docbookx.dtd
/usr/share/sgml/docbook/sgml-dtd-4.4-1.0-26/docbookx.dtd
/usr/share/sgml/docbook/sgml-dtd-4.3-1.0-26/docbookx.dtd
/usr/share/sgml/docbook/sgml-dtd-4.2-1.0-26/docbookx.dtd
/usr/share/sgml/docbook/xml-dtd-4.3-1.0-26/docbookx.dtd
/usr/share/sgml/docbook/xml-dtd-4.2-1.0-26/docbookx.dtd
/usr/share/sgml/docbook/xml-dtd-4.4-1.0-26/docbookx.dtd
/usr/share/sgml/docbook/xml-dtd-4.1.2-1.0-26/docbookx.dtd
---
However, only the last location could be detected with current 
configure script.

> > Imho it is bad idea to access internet for compilation
> > purposes without expilcit user permission to do this. Programs
> > shouldn't surf the internet on their own. This can be optional
> > but _not_ default behaviour.
>
> It's not default. It's fallback if everything else fails.
> Current behaviour guarantees failure, as it sets the _required_
> DTD path to a path that already was checked and didn't contain
> the DTD. A fallback to internet at least gives some chances of
> success.

Yes it is usefull in such case, but I don't want to allow any 
progams to access internet beyond my eyes and without my 
permission.

> If it's really an issue I can modify patch to use http only if
> --use-http was passed to configure, but there are some problems
> with it: 1) It'll be the first command-line argument to
> configure. More will likely follow, so some proper general
> parsing is to be done. 

Maybe bash builtin getopt will help? If you don't want rely on 
bash, you may use external getopt program.

> 2) what if user passed --use-http and 
> proper DTD exists? Which one should be used? Maybe two different
> options --fallback-to-http and --force-http? Even more ugly. And
> it makes configure more complicated, like the main one is.

Perhaps, another solution exists: issue an error message about 
missing DTD, and print help message with link to the address from 
which DTD must be downloaded?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-docs/attachments/20070104/2b111ffc/attachment.pgp>