Bug 830951 - RFE: Improve mechanism of registering in sgml-common/xml-common catalog
RFE: Improve mechanism of registering in sgml-common/xml-common catalog
Status: ASSIGNED
Product: Fedora
Classification: Fedora
Component: sgml-common (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-11 14:42 EDT by Mauro Carvalho Chehab
Modified: 2013-07-04 19:01 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Old catalog file (3.74 KB, application/octet-stream)
2012-06-11 15:56 EDT, Mauro Carvalho Chehab
no flags Details
New catalog file, as installed together with xml-common-0.6.3-36.fc17.noarch (1.14 KB, application/octet-stream)
2012-06-11 15:57 EDT, Mauro Carvalho Chehab
no flags Details

  None (edit)
Description Mauro Carvalho Chehab 2012-06-11 14:42:43 EDT
Description of problem:

An error happens when trying to do a "make htmldocs" at upstream's Linux Kernel. 

The error is:

I/O error : Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl
warning: failed to load external entity "http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl"
compilation error: file /tmp/xmlto-xsl.4qdh73 line 4 element import
xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl

Version-Release number of selected component (if applicable):

    xmlto-0.0.25-2.fc17.x86_64

How reproducible:

Always

Additional info:

A quick fix is to install docbook-style-xsl-1.76.1-5.fc17.noarch and edit /usr/share/xmlto/format/docbook/xhtml, replacing:
   echo "http://docbook.sourceforge.net/release/xsl/current/xhtml/chunk.xsl"

by:
   echo "/usr/share/sgml/docbook/xsl-stylesheets-1.76.1/xhtml/chunk.xsl"
Comment 1 Ondrej Vasik 2012-06-11 15:24:59 EDT
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.
Comment 2 Mauro Carvalho Chehab 2012-06-11 15:55:30 EDT
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.
Comment 3 Mauro Carvalho Chehab 2012-06-11 15:56:10 EDT
Created attachment 591018 [details]
Old catalog file
Comment 4 Mauro Carvalho Chehab 2012-06-11 15:57:00 EDT
Created attachment 591019 [details]
New catalog file, as installed together with xml-common-0.6.3-36.fc17.noarch
Comment 5 Ondrej Vasik 2012-06-11 16:17:13 EDT
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.
Comment 6 Mauro Carvalho Chehab 2012-06-11 16:22:46 EDT
(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.
Comment 7 Mauro Carvalho Chehab 2012-06-11 16:49:26 EDT
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.
Comment 8 Ondrej Vasik 2012-06-11 16:59:13 EDT
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.
Comment 9 Mauro Carvalho Chehab 2012-06-11 17:06:31 EDT
(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.

Note You need to log in before you can comment on or make changes to this bug.