Bug 830951

Thanks for report, but the online version there is correct - and your suggestion is just dirty solution. 
It seems you have something wrong with your /etc/xml/catalog file - and that your local docbook-style-xsl package is not registered properly there... Could you please check this? As when the catalog from xml-common package is there, it should be translated automatically. Moving to docbook-style-xsl, but it might be some dependency issue.

I removed and re-installed the xml-common package:

# rpm -e xml-common-0.6.3-36.fc17.noarch --nodeps
# yum install -y xml-common

(installed version: xml-common-0.6.3-36.fc17.noarch)

The newly-installed catalog is shorter than the previous one.

 $ ls -la catalog*
-rw-r--r--  1 root root 1171 Jan 14 21:20 catalog
-rw-r--r--. 1 root root 3832 Jun 11 15:25 catalog.rpmsave

Still, xmlto doesn't work.

I'll append the new catalog file for reference.

Created attachment 591018 [details]
Old catalog file

Created attachment 591019 [details]
New catalog file, as installed together with xml-common-0.6.3-36.fc17.noarch

From catalog.rpmsave is clear that only docbook5 xsl stylesheets are installed in the catalog. This is incorrect, you need docbook-style-xsl to handle docbook 4 document.

I think you don't understand how the docbook xml/sgml catalogs work... packages do register themselves in post part of the installation and deregister in postun . When you reinstall the xml-common package, xml catalog gets cleared - and all packages registered in the past have to be reinstalled or reregistered. This is quite unfortunate, but rpm doesn't have any usable way how to handle it (I tried triggers in the past, but it was not producing correct results). So far it's either not a bug or some dependency issue... 

Question is how you managed to install xmlto without docbook-style-xsl properly registered - as xmlto requires this package - and docbook-style-xsl requires xml-common (so it should be installed/registered in correct order). As this bugzilla seems to be kind of dependency order issue - or incorrect package handling by user.

(In reply to comment #5)
> From catalog.rpmsave is clear that only docbook5 xsl stylesheets are
> installed in the catalog. This is incorrect, you need docbook-style-xsl to
> handle docbook 4 document.
> 
> I think you don't understand how the docbook xml/sgml catalogs work...
> packages do register themselves in post part of the installation and
> deregister in postun . When you reinstall the xml-common package, xml
> catalog gets cleared - and all packages registered in the past have to be
> reinstalled or reregistered. This is quite unfortunate, but rpm doesn't have
> any usable way how to handle it (I tried triggers in the past, but it was
> not producing correct results). So far it's either not a bug or some
> dependency issue... 

Isn't there any script that would check what xml files exist and re-generate the xml catalog? 

> Question is how you managed to install xmlto without docbook-style-xsl
> properly registered - as xmlto requires this package - and docbook-style-xsl
> requires xml-common (so it should be installed/registered in correct order).
> As this bugzilla seems to be kind of dependency order issue - or incorrect
> package handling by user.

Building Kernel docbook's were working properly with F16. They stopped working after "preupgrade" upgrade to F17. So, I suspect that maybe the rpm postinstall scripts are not doing the right thing at version upgrade.

After removing and re-inserting a series of packages (all style packages), the catalog is now right, and I'm now able to generate the docbooks properly. Yet, it would be great to have a script that would just re-run the xmlcatalog command for all installed packages, rebuilding the /etc/xml/catalog file. That would avoid upgrade issues.

I don't see how such script could be done in correct way. I own most of the packages registering there, so I could probably make some verification script for them, still, there might be others in other repositories and such script will miss them. Anyway - thanks for the suggestion.

You are probably right about preupgrade - probably some dependencies or post/postun order went wrong during the preupgrade transaction.

(In reply to comment #8)
> I don't see how such script could be done in correct way.

Maybe each package could create a /etc/xml/config.d file with the needed stuff. Then, the catalog could either include it or be generated based on config.d contents, via a simple script.

> I own most of the
> packages registering there, so I could probably make some verification
> script for them, still, there might be others in other repositories and such
> script will miss them. Anyway - thanks for the suggestion.
> 
> You are probably right about preupgrade - probably some dependencies or
> post/postun order went wrong during the preupgrade transaction.

Yeah, likely, docbook-style-xsl (and other styles) were upgraded before xml-common. As xml-common rewrites the catalog, that broke upgrading.

I've revisited the issue, and since there are no updates, I'm closing it as WONTFIX. Upstream has made some changes to the package. I do not think it is necessary to fix this now.
Please let us know if there is an important reason to keep working on this.