Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
Hi all, just for the record, I tested Agustin's patch, and it works very well. We have a similar problem in Ubuntu with the same root cause [1], just a slightly different apperance (we move from scrollkeeper to rarian-compat during the upgrade, and the latter makes things blow up). In Debian we not affected by this case, since we don't automatically change scrollkeeper to rarian-compat in Lenny; and after Lenny is released, an auto-upgrade from scrollkeeper to rarian-compat in Lenny+1 will have a fixed update-xmlcatalog in all cases. So I won't forward any Pre-Depends: or similar change Ubuntu does to rarian-compat to Debian. Many thanks, Martin [1] https://bugs.launchpad.net/bugs/256131 -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
tag 482140 - unreproducible thanks On Fri, Oct 10, 2008 at 04:14:27PM +0200, Agustin Martin wrote: On Tue, Oct 07, 2008 at 05:51:20PM +0200, Daniel Leidert wrote: Examining bug #482140 I found, that update-xmlcatalog fails during dist-upgrade from Etch to Lenny with an Error, that Functions.pm cannot be found in @INC (the same goes for defoma-app, IIRC there Copy.pm was not found). The paths in @INC were only the generic paths and the 5.8 paths, but the 5.10 paths were missing. Finally reproduced. Do not know what gnome triggers here, probably changes package installation ordering, causing the error condition. Trying without gnome installed I could not reproduce the error. Here's a simple recipe, starting with a clean Etch chroot: # apt-get install docbook-xml # sed -i s/etch/lenny/ /etc/apt/sources.list # apt-get update # apt-get -d install perl-modules docbook-xml # cd /var/cache/apt/archives # dpkg --unpack perl-modules_5.10.0-*.deb docbook-xml_4.5-5*.deb [...] Can't locate File/Spec/Functions.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/sbin/update-xmlcatalog line 124. BEGIN failed--compilation aborted at /usr/sbin/update-xmlcatalog line 124. Removing obsolete conffile /etc/sgml/docbook-xml/3.1.7/dbgenent.ent ... Unpacking replacement docbook-xml ... # apt-get -f dist-upgrade [...] Setting up docbook-xml (4.5-5) ... update-xmlcatalog: error: entity already registered dpkg: error processing docbook-xml (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: docbook-xml I still think the only options to fix this for sure are to change the docbook-xml postinst or to make the package pre-depend on a fixed xml-core. Fortunately docbook-xml does seem to be the only package affected after all. I've gone through my earlier list of packages using dh_installxmlcatalogs, and there are only six packages with a newer version in Lenny than in Etch. Out of these, all the other five can be upgraded succesfully with the above recipe. I think (but haven't systematically verified) that the other five succeed because they re-register the same catalog information in the postinst, so it doesn't matter that 'prerm upgrade' failed to remove the old information. (The update-xmlcatalog script only bails out with an error if asked to add catalog information with an existing key but different contents. If the key and the contents match existing data, it will just exit succesfully.) For reference, the packages I've gone through are docbook-xsl docbook-ebnf docbook-simple scrollkeeper openoffice.org-dtd-officedocument1.0 -- Niko Tyni [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
Am Samstag, den 11.10.2008, 12:27 +0300 schrieb Niko Tyni: On Fri, Oct 10, 2008 at 04:14:27PM +0200, Agustin Martin wrote: On Tue, Oct 07, 2008 at 05:51:20PM +0200, Daniel Leidert wrote: [..] Here's a simple recipe, starting with a clean Etch chroot: Thanks. [..] I still think the only options to fix this for sure are to change the docbook-xml postinst or to make the package pre-depend on a fixed xml-core. I will go for an and not an or. I will remove the 2 offending entities in the postinst again and I will fix update-xmlcatalog and make docbook-xml pre-depend on it. I hope, this will make sure, that everything works. I will also check the Sarge package. Fortunately docbook-xml does seem to be the only package affected after all. Yes, there I changed 2 entities. The other should ship only new entities, not changed ones (at least those I maintain). But I will check myself too (you did not test all :)). Many thanks (to you, Agustin and the others) for your help. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
On Wed, Oct 08, 2008 at 08:29:02PM +0200, Agustin Martin wrote: I am afraid the only way to make sure is following Niko proposal about pre-dependencies on a newer and fixed xml-core. Me may be lucky and do not need any of this. See below for a possible fix. On Tue, Oct 07, 2008 at 05:51:20PM +0200, Daniel Leidert wrote: Hi all, Examining bug #482140 I found, that update-xmlcatalog fails during dist-upgrade from Etch to Lenny with an Error, that Functions.pm cannot be found in @INC (the same goes for defoma-app, IIRC there Copy.pm was not found). The paths in @INC were only the generic paths and the 5.8 paths, but the 5.10 paths were missing. I wonder, how to solve the problem. The problem is reprosucible in my pbuilder (Etch-)CHROOT doing: apt-get install docbook-xml vim apt-get install gnome Finally reproduced. Do not know what gnome triggers here, probably changes package installation ordering, causing the error condition. Trying without gnome installed I could not reproduce the error. The *good news* are that seems I have a patch to xml-core that makes this bug not being triggered, at least with gnome. An xml-core package with the changes is available through deb http://people.debian.org/~agmartin/debian-store/experimental ./ For inclusion with 'apt-key add', repository is signed with my Debian key, available from the Debian keyring. It contains a number of changes that should IMHO, go into xml-core, * tools/update-xmlcatalog: - Use perl-base File::Spec rather than perl-modules File::Spec::Functions. - Call catfile as a File::Spec method instead of as a function. * debian/rules: - Pass -d option to dh_perl, we no longer use anything outside perl-base. This is important, because, unless I am wrong it was the only call to something outside perl-base. Seems that after the change all perl modules used in xml-core update-xmlcatalogs File::Spec Getopt::Long vars are now in perl-base (or in debhelper for Debian::Debhelper::Dh_Lib use in dh_installxmlcatalogs), so we can drop the dependency on full perl (better pass -d option to dh_perl, so looks for versioned dependency in perl-base if any) *This really needs to be double-checked*, but seems I did not miss any non perl-base module. * debian/rules: - Make sure auto-generated man pages are removed on clean target. * tools/update-xmlcatalog: - Be more verbose if error is signalled on already registered entity. As you see above, I added a couple of things in the patch. Make failure a bit more verbose and remove auto-generated man pages from clean target. Note that I finally used the File::Spec-catfile way, so full portability is preserved. I am not a perl wizard, so I keep debian-perl cc'ed in case people there see problems I am missing. Not sure that this will fix all uses, but seems that at least works well with the interaction with gnome. For further checking, and may be (I hope not) to identify other scenarios for this bug, I am Bcc'ing the people that reported reproducing the bug, in case they want to try with my package. Sorry if I missed someone. As told above, my repo is signed with my gpg key, available at the Debian keyring. Patch is attached. -- Agustin diff -Nru xml-core-0.11/debian/changelog xml-core-0.11.0.amd1/debian/changelog --- xml-core-0.11/debian/changelog 2007-04-16 19:18:15.0 +0200 +++ xml-core-0.11.0.amd1/debian/changelog 2008-10-09 19:29:59.0 +0200 @@ -1,3 +1,15 @@ +xml-core (0.11.0.amd1) unstable; urgency=low + + * tools/update-xmlcatalog: +- Use perl-base File::Spec rather than perl-modules File::Spec::Functions. +- Call catfile as a File::Spec method instead of as a function. +- Be more verbose if error is signalled on already registered entity. + * debian/rules: +- Pass -d option to dh_perl, we no longer use anything outside perl-base. +- Make sure auto-generated man pages are removed on clean target. + + -- Agustin Martin Domingo [EMAIL PROTECTED] Thu, 09 Oct 2008 19:29:59 +0200 + xml-core (0.11) unstable; urgency=low [ Daniel Leidert ] diff -Nru xml-core-0.11/debian/rules xml-core-0.11.0.amd1/debian/rules --- xml-core-0.11/debian/rules 2007-04-14 21:40:30.0 +0200 +++ xml-core-0.11.0.amd1/debian/rules 2008-10-09 19:28:07.0 +0200 @@ -16,6 +16,7 @@ clean: dh_testdir dh_testroot + rm -f tools/update-xmlcatalog.8 debhelper/dh_installxmlcatalogs.1 dh_clean rm -f build-stamp install-stamp @@ -47,7 +48,7 @@ dh_compress dh_fixperms dh_installdeb - dh_perl + dh_perl -d dh_gencontrol dh_md5sums dh_builddeb diff -Nru xml-core-0.11/tools/update-xmlcatalog xml-core-0.11.0.amd1/tools/update-xmlcatalog --- xml-core-0.11/tools/update-xmlcatalog 2007-04-14 21:43:46.0 +0200 +++ xml-core-0.11.0.amd1/tools/update-xmlcatalog 2008-10-09 19:10:55.0 +0200 @@ -121,7 +121,7 @@ use strict; ## -- -use File::Spec::Functions; +use
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
On Tue, 07 Oct 2008, Daniel Leidert wrote:
Remove the `|| true' statements in /var/lib/dpkg/info/docbook-xml.prerm
and add an `set -ex' at the top and you will get the error doing:
A prerm cannot rely on packages being configured unless you predepend on
them. But predependencies are to be avoided. Ideally you only use stuff
from Essential in such scripts or you have sane fallback in case you
encounter problems.
Pre-Depends: perl, perl-modules
for xml-core and I hope, it works. But I'm not sure. What is your
opinion?
It should work but I wouldn't go for this solution. See below.
On Wed, 08 Oct 2008, Damyan Ivanov wrote:
-=| Agustin Martin, Wed, Oct 08, 2008 at 12:45:30AM +0200 |=-
Looking at /usr/sbin/update-xmlcatalog, seems that only
File::Spec::Functions function used is 'catfile' whose calls should be
pretty simple to replace,
From File::Spec::Unix (where File::Spec::Functions points to)
catfile Concatenate one or more directory names and a filename to form
a complete path ending with a filename
I am attaching a fully untested quick and dirty patch, intending to get rid
of File::Spec::Functions by replacing 'catfile' calls.
File::Spec provides a portable way of creating filesystem paths. Your
patch would break portability.
Not a big deal I would say. But if it's important then you can always use
this non-portable function as a fallback only:
BEGIN {
eval 'use File::Spec';
if ($@) {
eval q{
sub catfile { return join(/, @_); }
};
}
}
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
On Wed, Oct 08, 2008 at 09:50:02AM +0200, Raphael Hertzog wrote:
On Wed, 08 Oct 2008, Damyan Ivanov wrote:
-=| Agustin Martin, Wed, Oct 08, 2008 at 12:45:30AM +0200 |=-
I am attaching a fully untested quick and dirty patch, intending to get
rid
of File::Spec::Functions by replacing 'catfile' calls.
File::Spec provides a portable way of creating filesystem paths. Your
patch would break portability.
Not a big deal I would say. But if it's important then you can always use
this non-portable function as a fallback only:
BEGIN {
eval 'use File::Spec';
if ($@) {
eval q{
sub catfile { return join(/, @_); }
};
}
}
I like this one, although I guess you mean 'File::Spec::Functions'
instead of 'File::Spec'.
This script is Debian-only, so full portability is not that important.
But if people strongly thinks otherwise, and 'File::Spec', from perl-base,
is properly available during all the upgrade, using it and
'File::Spec-catfile', like in attached patch, is another approach.
This, regarding modifications to update-xmlcatalog in the short term. After
lenny this probably needs to be rewritten to work from postinst as Niko
suggests.
However, that is only one part of the problem. The other part is what
happens if docbook-xml is unpacked before new xml-core is unpacked and
before perl-modules is configured. Seems that unpacking is done in
alphabetical order (and seems that people finds this problem in
docbook-xml because it goes early in the alphabetical list), and thus,
docbook-xml goes before xml-core (at least in normal apt-get runs, did
not try with dist-upgrade), and so prerm is run with old xml-core script,
failing. I wonder why this sometimes does not fail.
I am afraid the only way to make sure is following Niko proposal about
pre-dependencies on a newer and fixed xml-core.
--
Agustin
--- update-xmlcatalog.orig 2008-10-08 00:20:48.0 +0200
+++ update-xmlcatalog 2008-10-08 19:01:14.0 +0200
@@ -121,7 +121,7 @@
use strict;
## --
-use File::Spec::Functions;
+use File::Spec;
use Getopt::Long;
## --
@@ -196,7 +196,7 @@
{
if ( defined( $package ) )
{
- my $catalog = catfile( $catalog_dir, $package.xml );
+ my $catalog = File::Spec-catfile( $catalog_dir, $package.xml );
if ( ! -f $catalog )
{
print STDERR $name: error: package catalog $catalog not found\n;
@@ -261,7 +261,7 @@
{
if ( defined( $root ) )
{
- my $catalog = catfile( $catalog_dir, 'catalog' );
+ my $catalog = File::Spec-catfile( $catalog_dir, 'catalog' );
if ( ! -f $catalog )
{
print STDERR $name: error: root catalog $catalog not found\n;
@@ -275,7 +275,7 @@
}
elsif ( defined( $package ) )
{
- my $catalog = catfile( $catalog_dir, $package.xml );
+ my $catalog = File::Spec-catfile( $catalog_dir, $package.xml );
if ( ! -f $catalog )
{
print STDERR $name: error: package catalog $catalog not found\n;
@@ -344,8 +344,8 @@
if ( defined( $root ) )
{
$catalog = 'catalog';
-$catalog_data = catfile( $catalog_data_dir, $catalog );
-$catalog = catfile( $catalog_dir, $catalog );
+$catalog_data = File::Spec-catfile( $catalog_data_dir, $catalog );
+$catalog = File::Spec-catfile( $catalog_dir, $catalog );
my $start = $type;
$start .= 'Id' unless $type eq 'uri';
$start .= 'StartString';
@@ -358,8 +358,8 @@
}
elsif ( defined( $package ) )
{
-$catalog_data = catfile( $catalog_data_dir, $package );
-$catalog = catfile( $catalog_dir, $package.xml );
+$catalog_data = File::Spec-catfile( $catalog_data_dir, $package );
+$catalog = File::Spec-catfile( $catalog_dir, $package.xml );
my $start = $type;
$start .= 'Id' unless $type eq 'uri';
$start .= 'StartString';
@@ -375,7 +375,7 @@
$catalog = $local;
$catalog_data = $local;
$catalog_data =~ tr|/|_|;
-$catalog_data = catfile( $catalog_data_dir, $catalog_data );
+$catalog_data = File::Spec-catfile( $catalog_data_dir, $catalog_data );
my $start = ( $type eq 'uri' ) ? 'name' : $type;
$start .= 'Id' unless $type eq 'uri';
$id = $start=\$id\;
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
Hi all, Examining bug #482140 I found, that update-xmlcatalog fails during dist-upgrade from Etch to Lenny with an Error, that Functions.pm cannot be found in @INC (the same goes for defoma-app, IIRC there Copy.pm was not found). The paths in @INC were only the generic paths and the 5.8 paths, but the 5.10 paths were missing. I wonder, how to solve the problem. The problem is reprosucible in my pbuilder (Etch-)CHROOT doing: apt-get install docbook-xml vim apt-get install gnome (unfortunately I cannot yet reproduce it with a smaller subset of packages) vim /etc/apt/sources.list (etch - lenny) apt-get update Remove the `|| true' statements in /var/lib/dpkg/info/docbook-xml.prerm and add an `set -ex' at the top and you will get the error doing: apt-get dist-upgrade Unfortunately I removed the log. But I will produce a new one and send relevant parts in a second mail. I hope, I understood the log correctly. ATM I think of using a Pre-Depends: perl, perl-modules for xml-core and I hope, it works. But I'm not sure. What is your opinion? Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
Am Dienstag, den 07.10.2008, 17:51 +0200 schrieb Daniel Leidert: Examining bug #482140 I found, that update-xmlcatalog fails during dist-upgrade from Etch to Lenny with an Error, that Functions.pm cannot be found in @INC (the same goes for defoma-app, IIRC there Copy.pm was not found). The paths in @INC were only the generic paths and the 5.8 paths, but the 5.10 paths were missing. Here the log output: Preparing to replace fontconfig 2.4.2-1.2 (using .../fontconfig_2.6.0-1_i386.deb) ... Can't locate File/Copy.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share /perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/bin/defoma-app line 7. BEGIN failed--compilation aborted at /usr/bin/defoma-app line 7. dpkg: warning - old pre-removal script returned error exit status 2 dpkg - trying script from the new package instead ... dpkg: ... it looks like that went OK. and for update-xmlcatalog: Preparing to replace docbook-xml 4.4-5 (using .../docbook-xml_4.5-5_all.deb) ... Can't locate File/Spec/Functions.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.8.8 /usr/local/share/perl/5.8.8 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.8 /usr/share/perl/5.8 /usr/local/lib/site_perl .) at /usr/sbin/update-xmlcatalog line 124. BEGIN failed--compilation aborted at /usr/sbin/update-xmlcatalog line 124. I guess, update-xmlcatalog still fails by trying the prerm script from the new version - we just don't see it because of the `|| true' statements in it. And thus the bug #482140 is observed. The issue does not occur, if perl and perl-modules are updated/installed before I try to update docbook-xml. In this case, everything works fine. Ideas are appreciated. Regards, Daniel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
On Tue, Oct 07, 2008 at 05:51:20PM +0200, Daniel Leidert wrote:
Hi all,
Examining bug #482140 I found, that update-xmlcatalog fails during
dist-upgrade from Etch to Lenny with an Error, that Functions.pm cannot
be found in @INC (the same goes for defoma-app, IIRC there Copy.pm was
not found). The paths in @INC were only the generic paths and the 5.8
paths, but the 5.10 paths were missing.
I wonder, how to solve the problem. The problem is reprosucible in my
pbuilder (Etch-)CHROOT doing:
apt-get install docbook-xml vim
apt-get install gnome
(unfortunately I cannot yet reproduce it with a smaller subset of
packages)
This is another thing, why this sometimes appear and sometimes not. But that
is at least something to start with. Jump to the bottom of the message if
short of time.
One for the not found score. I tried from a pbuilder (Etch-)CHROOT, installing
apt-get install w3c-dtd-xhtml docbook-xml scrollkeeper
just to try reproducing one of the contributors setup. Then change
sources.list and
apt-get update
apt-get dist-upgrade
Upgrading suceeded (besides some manual action needed because of tzdata, I had
to enable Force-LoopBreak for apt. Nobody else found this?)
I am not at that box now, and will not be at a real box (something not too
slow) at least for a couple of days. Will try again when possible, but I
would really like to know what causes this annoyant behavior.
vim /etc/apt/sources.list (etch - lenny)
apt-get update
Remove the `|| true' statements in /var/lib/dpkg/info/docbook-xml.prerm
and add an `set -ex' at the top and you will get the error doing:
apt-get dist-upgrade
Unfortunately I removed the log. But I will produce a new one and send
relevant parts in a second mail. I hope, I understood the log correctly.
ATM I think of using a
Pre-Depends: perl, perl-modules
for xml-core and I hope, it works. But I'm not sure. What is your
opinion?
Looking at /usr/sbin/update-xmlcatalog, seems that only
File::Spec::Functions function used is 'catfile' whose calls should be
pretty simple to replace,
From File::Spec::Unix (where File::Spec::Functions points to)
catfile Concatenate one or more directory names and a filename to form
a complete path ending with a filename
I am attaching a fully untested quick and dirty patch, intending to get rid
of File::Spec::Functions by replacing 'catfile' calls.
Hope this helps,
--
Agustin
--- update-xmlcatalog.orig 2008-10-08 00:20:48.0 +0200
+++ update-xmlcatalog 2008-10-08 00:33:57.0 +0200
@@ -121,7 +121,6 @@
use strict;
## --
-use File::Spec::Functions;
use Getopt::Long;
## --
@@ -196,7 +195,7 @@
{
if ( defined( $package ) )
{
- my $catalog = catfile( $catalog_dir, $package.xml );
+ my $catalog = $catalog_dir . /$package.xml;
if ( ! -f $catalog )
{
print STDERR $name: error: package catalog $catalog not found\n;
@@ -261,7 +260,7 @@
{
if ( defined( $root ) )
{
- my $catalog = catfile( $catalog_dir, 'catalog' );
+ my $catalog = $catalog_dir/catalog;
if ( ! -f $catalog )
{
print STDERR $name: error: root catalog $catalog not found\n;
@@ -275,7 +274,7 @@
}
elsif ( defined( $package ) )
{
- my $catalog = catfile( $catalog_dir, $package.xml );
+ my $catalog = $catalog_dir/$package.xml;
if ( ! -f $catalog )
{
print STDERR $name: error: package catalog $catalog not found\n;
@@ -344,8 +343,8 @@
if ( defined( $root ) )
{
$catalog = 'catalog';
-$catalog_data = catfile( $catalog_data_dir, $catalog );
-$catalog = catfile( $catalog_dir, $catalog );
+$catalog_data = $catalog_data_dir . / . $catalog;
+$catalog = $catalog_dir . / . $catalog;
my $start = $type;
$start .= 'Id' unless $type eq 'uri';
$start .= 'StartString';
@@ -358,8 +357,8 @@
}
elsif ( defined( $package ) )
{
-$catalog_data = catfile( $catalog_data_dir, $package );
-$catalog = catfile( $catalog_dir, $package.xml );
+$catalog_data = $catalog_data_dir . / . $package;
+$catalog = $catalog_dir . / . $package.xml;
my $start = $type;
$start .= 'Id' unless $type eq 'uri';
$start .= 'StartString';
@@ -375,7 +374,7 @@
$catalog = $local;
$catalog_data = $local;
$catalog_data =~ tr|/|_|;
-$catalog_data = catfile( $catalog_data_dir, $catalog_data );
+$catalog_data = $catalog_data_dir . / . $catalog_data;
my $start = ( $type eq 'uri' ) ? 'name' : $type;
$start .= 'Id' unless $type eq 'uri';
$id = $start=\$id\;
Bug#482140: etch - lenny upgrade fails, because @INC does not contain 5.10 paths
-=| Agustin Martin, Wed, Oct 08, 2008 at 12:45:30AM +0200 |=- Looking at /usr/sbin/update-xmlcatalog, seems that only File::Spec::Functions function used is 'catfile' whose calls should be pretty simple to replace, From File::Spec::Unix (where File::Spec::Functions points to) catfile Concatenate one or more directory names and a filename to form a complete path ending with a filename I am attaching a fully untested quick and dirty patch, intending to get rid of File::Spec::Functions by replacing 'catfile' calls. File::Spec provides a portable way of creating filesystem paths. Your patch would break portability. -- damJabberID: [EMAIL PROTECTED] signature.asc Description: Digital signature
