entities from the sgml-base maintainer
On Mar 30, Ardo van Rangelrooij (ardo@debian.org) wrote:
> Hi,
>
> Just a quick update on what's happening in 'sgml-base' land.
> '/usr/lib/sgml'
> ---------------
>
> This new version of 'sgml-base' will also contain code to clean up
> '/usr/lib/sgml'. Each invocation of 'install-sgmlcatalog --remove'
> checks whether the transitional catalog in '/usr/lib/sgml' is empty.
> If so, it's removed and unregistered from the supercatalog. Next, if
> '/usr/lib/sgml' is empty the symlink to the supercatalog is removed
> and the directory is removed.
>
> This is also the reason why packages with SGML catalogs still have
> the 'install-sgmlcatalog --remove' in their prerm script. There
> would be no other feasible way to remove '/usr/lib/sgml'.
>
>
> backwards compatibility symlinks
> --------------------------------
>
> Currently, the following packages have symlinks in '/usr/lib/sgml' for
> backwards compatibility: 'sgml-base', 'sgml-data', 'docbook-dsssl' and
> 'sp'.
>
> How long do we want to keep these? I would like to propose that we
> remove these in sarge+1.
Speaking as the maintainer of sp, how do we start the transition to dropping
the symlinks? What problems might occur if we drop the symlinks, and how do
we alert whoever would be affected that they need to change? If we are going
to drop the symlinks in sarge+1 and we need to do something to alert people
beforehand, we need to do that alerting in sarge, i.e., we need to do it soon.
The opensp package currently includes both /usr/lib/sgml and /usr/share/sgml
paths in its default search path for catalogs. It does not install any
catalogs itself. Does the above mean that I need to keep /usr/lib/sgml until
sarge+1?
--
Neil Roeth
Reply to: