Re: proposal to split sgml-base

[Adam Di Carlo <adam@onshore.com>]

Ardo_Vanrangelrooij <ardo@enteract.com> writes:

> Another solution is to start without /etc/sgml/catalog and have it in the postinst
> put in place from a template in /usr/share/sgml-base (similar to what I'm doing
> with the centralized catalogs).  We can do the same with the transitional.cat.

Right -- they wouldn't be conffiles at all, right?  Just managed by
the maintainer scripts.  This I think is the right course of action.

It seems to me that policy deprecates having a conffile be managed by
the maintainer scripts (and support programs):

Policy 11.7.3:

     [Using a 'conffile' rather than just a configuration file] is
     appropriate only if it is possible to distribute a default
     version that will work for most installations, although some
     system administrators may choose to modify it.  This implies that
     the default version will be part of the package distribution, and
     must not be modified by the maintainer scripts during
     installation (or at any other time).

     In order to ensure that local changes are preserved correctly, no
     package may contain or make hard links to conffiles.  [1]

     The other way to do it is via the maintainer scripts.  In this case,
     the configuration file must not be listed as a `conffile' and must not
     be part of the package distribution.

This *must* *not* seems to be specifically saying it's not right for
/etc/sgml/catalog to be a conffile, no?


> On the other hand I kinda like the idea of having a new package.  No need for 
> versioned dependencies and it clearly separates the old from the
> new.

Well, I didn't really fully understand the relationship (do they
conflict? depend on each other), but I trust you to do what is right.
I think it's getting a little confusing:

  sgml-base   # legacy xml/sgml catalog support etc
  sgml-common # new xml/sgml catalog support etc
  sgml-data   # common sgml/xml data

I think users are going to get confused.

Perhaps, if you do wanna have sgml-base be specifically a legacy
package, the new package could be called "sgml-infrastructure"
instead?

-- 
.....Adam Di Carlo....adam@onShore.com.....<URL:http://www.onShore.com/>