Re: proposal to split sgml-base
On Tue, Feb 20, 2001 at 11:44:43AM -0500, Adam Di Carlo wrote:
> 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?
Yes, you're right. Reading it for the xth time in a different context and
mood I (finally) get this. So, all files under /etc which are updated via
the various install and update tools in postinst/etc scripts should not be
conffiles, right?
> > 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.
sgml-base will depend on sgml-common. After the last package has been
moved from /usr/lib/sgml to /usr/share/sgml and thereby removed its stuff
from the transitional.cat, sgml-base can be safely removed from the
distribution.
> 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?
That's indeed a much better name. I'll think it over.
Thanks,
Ardo
Reply to: