On Tue, Feb 20, 2001 at 11:44:43AM -0500, Adam Di Carlo wrote: > Ardo_Vanrangelrooij <[EMAIL PROTECTED]> 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
