Bug#675309: nsgmls:/etc/sgml/mutter-common.cat:8:8:E: cannot open "/usr/share/sgml/mutter-common/catalog
biebl at debian.org
Thu May 31 13:52:57 UTC 2012
On 31.05.2012 13:47, Michael Biebl wrote:
> On 31.05.2012 09:20, Robert Luberda wrote:
>> po4a or any other program that calls nsgmls fails with:
>> nsgmls:/etc/sgml/mutter-common.cat:8:8:E: cannot open "/usr/share/sgml/mutter-common/catalog" (No such file or directory)
>> I can see in the changelog for 3.4.1-2 that removal of
>> mutter-common.catalog file was intentional but
>> /etc/sgml/mutter-common.cat still referes to it.
> Since update-catalog was responsible for installing this file into
> /etc/sgml, I'm wondering if it isn't also update-catalog's job to clean
> up the conffile once the package is removed or it stops shipping the
> catalog file.
In case of mutter-common the file /usr/share/sgml/mutter-common/catalog
is gone for good so I guess we can just forcefully remove
/etc/sgml/mutter-common.cat on upgrades.
I'm wondering though, what to do about metacity-common, which exposes
the same problem if the package is removed, but not purged.
Cleaning up the conffile on "remove" might be tricky, since you can't
just delete it. You'd have to move it away / rename it and move it back
if the package is re-installed.
> # cat /etc/sgml/metacity-common.cat
> CATALOG /usr/share/sgml/metacity-common/catalog
> # ls /usr/share/sgml/metacity-common/catalog
> ls: cannot access /usr/share/sgml/metacity-common/catalog: No such file
> or directory
As said, those dangling conffiles in /etc/sgml are a more general
problem. I'm wondering if nsgmls should handle that more gracefully/in a
more robust way.
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 900 bytes
Desc: OpenPGP digital signature
More information about the pkg-gnome-maintainers