[xml/sgml-pkgs] Bug#675309: nsgmls:/etc/sgml/mutter-common.cat:8:8:E: cannot open "/usr/share/sgml/mutter-common/catalog

Michael Biebl biebl at debian.org
Fri Jun 1 11:53:45 UTC 2012


clone 675309 -1
reassign -1 sgml-base
thanks

On 31.05.2012 15:52, Michael Biebl wrote:
> On 31.05.2012 13:47, Michael Biebl wrote:
>> Hi,
>>
>> 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.

I completely missed that those files are not conffiles but completely
managed by update-catalog via the maintainer scripts/dpkg triggers.

I'm cloning and re-assignig this bug to sgml-base.
It should handle the case of removed-but-not-purged packages in a way
that it doesn't break existing software like nsgmls.

As for mutter-common, I'll just rm -f the files on upgrade.

Michael



-- 
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...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/debian-xml-sgml-pkgs/attachments/20120601/8a363c05/attachment.pgp>


More information about the debian-xml-sgml-pkgs mailing list