Hi Norbert,
Thanks for your thoughts.
Pulling in Daniel Leidert as he seems to be the most active sgml related
maintainer.
On Wed, Jun 20, 2012 at 08:30:25AM +0900, Norbert Preining wrote:
> * I checked the update-catalogue script, and it simply interates over
> all .cat files in /etc/sgml. That by design is prone to break, as we
> saw.
It serves a purpose. The intended purpose is that users can add their
own .cat files and have them included via update-catalog --update-super,
like they could add their own catalogs to the super catalog before the
transition. Removing this ability is beyond the scope of my work.
> * the dh_installcatalogs generated code is not policy conform, well not
> even anything debian related. The configure (postinst) part simply
> does
> rm -f /etc/sgml/openjade.cat
> without any action in preinst or so.
> If you do this, it means that changes to config files under /etc/sgml/
> are *not* preserved
As is explained in precisely that preinst, this only happens if we are
upgrading from a version where the package catalog was not a conffile.
This losing of changes therefore happens one more time. Not removing
that file would cause every single user to see dpkg prompts about
conffile changes (even though they did not cause those changes).
> * If this is the case, that the files installed by update-catalog --add
> should not be edited at all, then please put them into /var/somewhere
> and all of the problems with rc are gone
The conclusion you draw here is wrong. Once they have a proper conffile
catalog in place, this is the intended way to change those files
(besides editing them).
> * another option would be to use ucf* to put them under dpkg conffile
> control when they are update-catalog --add, and remove them on
> purge from the ucf catalgoue.
> And in the --add action also use ucf to check for existence and status
> of the files there
I have no clue how ucf works. This is reason enough for me to try hard
to avoid this additional complexity unless there are convincing
arguments. I can look into it, if you insist that pursuing that path is
a useful exercise.
> But, my suggestion is actually to:
> - either put the .cat files into /var and not into /etc/sgml
Technically this would work. The transition would be painful for users.
The solution would also require rebuilding every dh_installcatalogs
user. => I would like to avoid this way.
> - or create them at dh_installcatalogue (package build) time, and
> let them be properly handled by dpkg. In this case also add a state
> file in /var/... so that update-catalog --supercatalog does know
> about which files should actually be included
The first part actually happens already. The package catalogs are
conffiles by now. The part with files in /var is missing. It is still
doable, causes the same rebuilding as above.
Both approaches remove the ability to add further catalogs. This is a
regression I do not want to introduce.
On Wed, Jun 20, 2012 at 07:29:35AM +0900, Norbert Preining wrote:
> In your case with historic left overs there are further problems. In this
> case I don't see much way but:
> - ship for each of the affected *old* packages the md5sum of the resepctive
> config file
I do not have the computational resources to do this. Technically I
would need all {pre,post}{inst,rm} that contains "sgml" or
"update-catalog" of every package ever created.
> - check at update (triggered I guess) of the cataolgue time whether the
> package is installed (and NO guessing by file name!, you can ship
> an array "old package name -> config file shipped")
In all cases I have seen the package name matches the config file,
because all besides one use dh_installcatalogs. So that guess seems
reasonable to me after all.
> - if the package is in rc state and the md5sum agrees with the one
> as originally shipped, remove it
> - if the package is in rc state and the md5sum disagrees, move/disable
> it and warn the admin
Lots of work...
> These are more or less the steps we had to do with old config files
> in /etc/texmf several times, too.
Let me explain another approach suggested by Joachim Breitner:
Basically having any reference to a non-existent catalog breaks the sgml
related tools. However this situation may be caused, it causes further
breakage. So maybe we can check the package (or user) catalogs in
/etc/sgml at trigger time. If a catalog references a file that does not
exist, a warning can be printed and the catalog be skipped.
This approach might need an explicit trigger activation in postrm
remove, because at this point the conffile is not removed. This needs to
be evaluated. (Thanks to Joachim Breitner for his attention to detail.)
This solution has a number of advantages:
1) Changes required only apply to sgml-base (and no other packages).
2) Works with both packages built with old and new debhelper.
3) If a user adds a broken catalog file, and issues update-catalog
--update-super, she will see a message and can correct her changes.
The obvious disadvantage is that I have to write a partial parser (at
least comments and CATALOG) in perl. It could also search for a special
"-- update-catalog:nocheck --" marker to skip further checks.
Any opinions?
Helmut
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
