[xml/sgml] Bug#283173: w3c-sgml-lib vs w3-dtd-mathml

[Nicholas Bamber]

Vincnet, Maathieu,
	Maybe after the freeze we should discuss making a clean up   a release 
goal for wheezy+1. It would be a rather small release goal, but it might 
not happen otherwise.


On 26/05/12 03:32, Vincent Lefevre wrote:
> On 2012-05-25 21:05:52 +0100, Nicholas Bamber wrote:
>> I am not sure what about w3c-dtd-mathml. However there is a long history
>> between w3c-dtd-xhtml and w3c-sgml-lib so I will assume it was a typo and
>> you meant w3c-dtd-xhtml.
>
> There was no typo. I wrote w3c-dtd-xhtml.
>
>> No you can't remove w3c-dtd-xhtml. Many , many more people depend on it
>> currently than w3c-sgml-lib. Look at the popcorn ratings.
>
> I don't see why w3-dtd-mathml should be treated differently from
> w3c-dtd-xhtml. Why would there be a conflict between w3c-sgml-lib
> and w3-dtd-mathml, but not between w3c-sgml-lib and w3c-dtd-xhtml?
> Note that like w3-dtd-mathml, w3c-dtd-xhtml provides entity files
> that are also in w3c-sgml-lib. So, if w3c-sgml-lib and
> {w3-dtd-mathml and/or w3c-dtd-xhtml} are installed at the same
> time, things can go wrong because the catalog can reference the
> same id (or prefix) to two different places at the same time.
>
>> That said they are totally trying to do the same thing. They even - check
>> the copyroght file  - have the same upstream. The difference is that
>> w3c-sgml-lib has a working watch file and leaves the upstream largely
>> untouched, whereas w3c-dtd-xhtml is just a random jumble of files vaguely
>> associated with the W3C.
>>
>> I have tried twice to make w3c-sgml-lib a drop in replacement for
>> w3c-dtd-xhtml and failed. As I see it the only way forward is to make the
>> reverse dependencies of w3c-dtd-xhtml depend instead on w3c-sgml-lib. Then
>> w3c-dtd-xhtml can be dropped. There is no way that should be attempted this
>> side of the freeze.
>
> OK.
>