Thread: horology regression test failure
Hi!
On almost all Debian platforms the horology test for 8.0.3 fails.
Sometimes it works on a platform, sometimes not, I did not yet find a
pattern, but most often it fails with something like
*** ./expected/horology.out Sun Jul 11 04:57:20 2004
--- ./results/horology.out Thu Sep 29 20:48:57 2005
***************
*** 1775,1784 ****
| Wed Mar 15 13:14:02 2000 PST | @ 34 years | Tue=
Mar 15 13:14:02 1966 PST
| Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sat=
Dec 31 17:32:01 1966 PST
| Mon Jan 01 17:32:01 2001 PST | @ 34 years | Sun=
Jan 01 17:32:01 1967 PST
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri=
Sep 22 18:19:20 1967 PDT
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu=
Jul 31 12:00:00 1969 PDT
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri=
Aug 01 00:00:00 1969 PDT
! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed=
Oct 01 00:00:00 1969 PDT
| Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon=
Dec 22 00:00:00 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue=
Dec 30 21:56:56 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed=
Dec 31 19:00:00 1969 PST
--- 1775,1784 ----
| Wed Mar 15 13:14:02 2000 PST | @ 34 years | Tue=
Mar 15 13:14:02 1966 PST
| Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sat=
Dec 31 17:32:01 1966 PST
| Mon Jan 01 17:32:01 2001 PST | @ 34 years | Sun=
Jan 01 17:32:01 1967 PST
! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri=
Sep 22 18:19:20 1967 PST
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu=
Jul 31 12:00:00 1969 PST
! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri=
Aug 01 00:00:00 1969 PST
! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed=
Oct 01 00:00:00 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon=
Dec 22 00:00:00 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue=
Dec 30 21:56:56 1969 PST
| Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed=
Dec 31 19:00:00 1969 PST
However, not even that is entirely consistent; the numbers are always
fine, but the second timezone is sometimes PST, sometimes PDT. Is this
problem known?
In case it matters, packages are configured with
--enable-nls \
--enable-integer-datetimes \
--enable-debug \
--disable-rpath \
--with-tcl \
--with-perl \
--with-python \
--with-pam \
--with-krb5 \
--with-openssl \
--with-gnu-ld \
--with-tclconfig=3D/usr/lib/tcl$(TCL_VER) \
--with-tkconfig=3D/usr/lib/tk$(TCL_VER) \
--with-includes=3D/usr/include/tcl$(TCL_VER):/usr/lib/R=
/include \
--with-pgport=3D5432 \
Thanks in advance!
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
On Thu, Sep 29, 2005 at 11:08:22PM +0200, Martin Pitt wrote: > On almost all Debian platforms the horology test for 8.0.3 fails. > Sometimes it works on a platform, sometimes not, I did not yet find a > pattern, but most often it fails with something like I think this test is supposed to fail when it's run near a DST transition. The question to be asking is, then, is the server running with a timezone that has just changed DST or is about to change? In this case, ignore the report. Note in the diff below that the originals have PDT (second column)/PDT (fourth column) while the result obtained from the test is PDT/PST; or PST/PDT and PST/PST; or PST/PST and PST/PDT. Does this explain the issue? > *** ./expected/horology.out Sun Jul 11 04:57:20 2004 > --- ./results/horology.out Thu Sep 29 20:48:57 2005 > *************** > *** 1775,1784 **** > | Wed Mar 15 13:14:02 2000 PST | @ 34 years | Tue Mar 15 13:14:02 1966 PST > | Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sat Dec 31 17:32:01 1966 PST > | Mon Jan 01 17:32:01 2001 PST | @ 34 years | Sun Jan 01 17:32:01 1967 PST > ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri Sep 22 18:19:20 1967 PDT > ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 12:00:00 1969 PDT > ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri Aug 01 00:00:00 1969 PDT > ! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed Oct 01 00:00:00 1969 PDT > | Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon Dec 22 00:00:00 1969 PST > | Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST > | Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed Dec 31 19:00:00 1969 PST > --- 1775,1784 ---- > | Wed Mar 15 13:14:02 2000 PST | @ 34 years | Tue Mar 15 13:14:02 1966 PST > | Sun Dec 31 17:32:01 2000 PST | @ 34 years | Sat Dec 31 17:32:01 1966 PST > | Mon Jan 01 17:32:01 2001 PST | @ 34 years | Sun Jan 01 17:32:01 1967 PST > ! | Sat Sep 22 18:19:20 2001 PDT | @ 34 years | Fri Sep 22 18:19:20 1967 PST > ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons 12 hours | Thu Jul 31 12:00:00 1969 PST > ! | Thu Jan 01 00:00:00 1970 PST | @ 5 mons | Fri Aug 01 00:00:00 1969 PST > ! | Thu Jan 01 00:00:00 1970 PST | @ 3 mons | Wed Oct 01 00:00:00 1969 PST > | Thu Jan 01 00:00:00 1970 PST | @ 10 days | Mon Dec 22 00:00:00 1969 PST > | Thu Jan 01 00:00:00 1970 PST | @ 1 day 2 hours 3 mins 4 secs | Tue Dec 30 21:56:56 1969 PST > | Thu Jan 01 00:00:00 1970 PST | @ 5 hours | Wed Dec 31 19:00:00 1969 PST -- Alvaro Herrera http://www.PlanetPostgreSQL.org "Porque Kim no hacia nada, pero, eso sí, con extraordinario éxito" ("Kim", Kipling)
Martin Pitt <martin@piware.de> writes:
> On almost all Debian platforms the horology test for 8.0.3 fails.
Before PG 8.0, I'd have said you were running with a timezone library
that didn't understand about DST before 1970. It shouldn't be happening
in 8.0 though.
regards, tom lane
Hi Tom! Tom Lane [2005-09-29 17:50 -0400]: > Martin Pitt <martin@piware.de> writes: > > On almost all Debian platforms the horology test for 8.0.3 fails. > > Before PG 8.0, I'd have said you were running with a timezone library > that didn't understand about DST before 1970. It shouldn't be happening > in 8.0 though. The underlying glibc is the same everywhere: Debian's 2.3.5 on all platforms and in all cases I tried it. And, for the record, the same problem happens with 8.1 beta 3. Thanks, Martin -- Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates?
Hi again! Martin Pitt [2005-09-29 23:08 +0200]: > Hi! >=20 > On almost all Debian platforms the horology test for 8.0.3 fails. > Sometimes it works on a platform, sometimes not, I did not yet find a > pattern, but most often it fails with something like > [...] I now think I know what is wrong here. This test has usually succeeded on my own computer, but it always fails on the Debian buildds (which build packages in a minimal chroot). As soon as I move away /usr/share/postgresql/8.1/timezone when building 8.1, the horology test fails. I. e. as long as the package that I currently build is already installed, then it works, but it fails if the package is not yet installed. The log entry seems to confirm this. I always get LOG: could not open directory "/usr/share/postgresql/8.0/timezone": No suc= h file or directory when running the 8.0 test suite on the debian buildds during package build. So it seems that the test suite uses the timezone files from the installed system instead of the files in the temporary installation in the regression test directory. Is there an easy way to fix that? Thanks! Martin --=20 Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates?
Martin Pitt <martin@piware.de> writes:
> So it seems that the test suite uses the timezone files from the
> installed system instead of the files in the temporary installation in
> the regression test directory.
It's not supposed to, and AFAICT it works fine for me (not only on my
personal machines, but also on Red Hat's build machines). Perhaps
you've done something to break the package-relocation logic? All those
files should be sought via paths relative to the postmaster executable.
regards, tom lane
Hi Tom!
Tom Lane [2005-12-20 12:49 -0500]:
> Martin Pitt <martin@piware.de> writes:
> > So it seems that the test suite uses the timezone files from the
> > installed system instead of the files in the temporary installation in
> > the regression test directory.
>=20
> It's not supposed to, and AFAICT it works fine for me (not only on my
> personal machines, but also on Red Hat's build machines). Perhaps
> you've done something to break the package-relocation logic? All those
> files should be sought via paths relative to the postmaster executable.
Maybe I did something wrong with the configure options. That bug is
reproducible with the pristine upstream 8.1.1 tarball and doing:
./configure --prefix=3D/usr --mandir=3D"\${prefix}/share/man" \
--sysconfdir=3D/etc --libdir=3D"\${prefix}/lib/postgresql/8.1/lib" \
--libexecdir=3D"\${prefix}/lib/postgresql-8.1/lib" \
--mandir=3D\${prefix}/share/postgresql/8.1/man \
--with-docdir=3D\${prefix}/share/doc/postgresql-doc-8.1 \
--datadir=3D\${prefix}/share/postgresql/8.1 \
--bindir=3D\${prefix}/lib/postgresql/8.1/bin \
--includedir=3D\${prefix}/include/postgresql/8.1
make
make check
However, it does *not* happen when I do not specify any configure
options at all. I'll try to narrow down the problematic change
further, but can you already see what the problem is here?
Thanks,
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
Hi!
Martin Pitt [2005-12-20 21:23 +0100]:
> Maybe I did something wrong with the configure options. That bug is
> reproducible with the pristine upstream 8.1.1 tarball and doing:
>=20
> ./configure --prefix=3D/usr --mandir=3D"\${prefix}/share/man" \
> --sysconfdir=3D/etc --libdir=3D"\${prefix}/lib/postgresql/8.1/lib" \
> --libexecdir=3D"\${prefix}/lib/postgresql-8.1/lib" \
> --mandir=3D\${prefix}/share/postgresql/8.1/man \
> --with-docdir=3D\${prefix}/share/doc/postgresql-doc-8.1 \
> --datadir=3D\${prefix}/share/postgresql/8.1 \
> --bindir=3D\${prefix}/lib/postgresql/8.1/bin \
> --includedir=3D\${prefix}/include/postgresql/8.1
A mere
./configure --libdir=3D/usr/lib/postgresql/8.1/lib --bindir=3D/usr/lib/pos=
tgresql/8.1/bin
is enough to reproduce the problem. With only --libdir, it works, and
with only --bindir the test suite does not run at all because the
postmaster cannot find $libdir (but that is still justifiable).
Thanks,
Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
In a world without walls and fences, who needs Windows and Gates?
Martin Pitt <martin@piware.de> writes:
> Maybe I did something wrong with the configure options. That bug is
> reproducible with the pristine upstream 8.1.1 tarball and doing:
> =2E/configure --prefix=/usr --mandir="\${prefix}/share/man" \
> --sysconfdir=/etc --libdir="\${prefix}/lib/postgresql/8.1/lib" \
> --libexecdir="\${prefix}/lib/postgresql-8.1/lib" \
> --mandir=\${prefix}/share/postgresql/8.1/man \
> --with-docdir=\${prefix}/share/doc/postgresql-doc-8.1 \
> --datadir=\${prefix}/share/postgresql/8.1 \
> --bindir=\${prefix}/lib/postgresql/8.1/bin \
> --includedir=\${prefix}/include/postgresql/8.1
> However, it does *not* happen when I do not specify any configure
> options at all. I'll try to narrow down the problematic change
> further, but can you already see what the problem is here?
Yeah, the chosen-at-random pathnames ;-). I quote from the comments
for make_relative_path():
* This function exists to support relocation of installation trees.
*
* ret_path is the output area (must be of size MAXPGPATH)
* target_path is the compiled-in path to the directory we want to find
* bin_path is the compiled-in path to the directory of executables
* my_exec_path is the actual location of my executable
*
* If target_path matches bin_path up to the last directory component of
* bin_path, then we build the result as my_exec_path (less the executable
* name and last directory) joined to the non-matching part of target_path.
* Otherwise, we return target_path as-is.
*
* For example:
* target_path = '/usr/local/share/postgresql'
* bin_path = '/usr/local/bin'
* my_exec_path = '/opt/pgsql/bin/postmaster'
* Given these inputs we would return '/opt/pgsql/share/postgresql'
In short, you can set --prefix however you want, but you really can't
tack random decoration between --prefix and /bin, /share and friends;
else make_relative_path will be unable to figure out how to transform
one to the other.
We could doubtless improve make_relative_path to some extent, but the
mess you have above seems impossible to deal with. How is a mere
program supposed to deduce where things were moved to, given only
knowledge of the actual location of --bindir? I see little if any
pattern that would allow prediction of the corresponding --datadir,
let alone --libexecdir or --includedir ...
regards, tom lane
Martin Pitt <martin@piware.de> writes:
> ./configure --libdir=3D/usr/lib/postgresql/8.1/lib --bindir=3D/usr/lib/pos=
> tgresql/8.1/bin
> is enough to reproduce the problem. With only --libdir, it works, and
> with only --bindir the test suite does not run at all because the
> postmaster cannot find $libdir (but that is still justifiable).
Try adding --datadir=/usr/lib/postgresql/8.1/share to that. Actually,
you'd be best off replacing all three options with
--prefix=/usr/lib/postgresql/8.1
because that will make sure that the entire installation is consistent.
regards, tom lane
Hi! Tom Lane [2005-12-20 16:39 -0500]: > Yeah, the chosen-at-random pathnames ;-). It's not that random, these are the paths that the FHS and Debian policy prescribe for this package's structure (multiple versions installable in parallel). :)=20 > I quote from the comments for make_relative_path(): Thanks, that was enlightening. > In short, you can set --prefix however you want, but you really can't > tack random decoration between --prefix and /bin, /share and friends; > else make_relative_path will be unable to figure out how to transform > one to the other. I see, that at least makes the reason for the failure plausible. However, if --bindir etc. cannot be set, then maybe configure should not offer these options? OTOH the only thing that actually breaks is the horology test suite, everything else works just fine since files shipped in a package are never relocated. > We could doubtless improve make_relative_path to some extent, but the > mess you have above seems impossible to deal with. How is a mere > program supposed to deduce where things were moved to, given only > knowledge of the actual location of --bindir? I see little if any > pattern that would allow prediction of the corresponding --datadir, > let alone --libexecdir or --includedir ... Right, with make_relative_path's current approach that seems to be impossible. However, in a test suite I had expected a semantics like $DESTDIR, i. e. instead of mangling the path somewhere in the middle, the test suite should just prepend the tmp_check path. It seems that the needs of the upstream tarball handling and the needs of packaging differ somewhat. But instead of hacking in the interiors of path handling, I will rather try another easy workaround. Thanks, Martin --=20 Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org
Hi! Tom Lane [2005-12-20 17:16 -0500]: > Martin Pitt <martin@piware.de> writes: > > ./configure --libdir=3D3D/usr/lib/postgresql/8.1/lib --bindir=3D3D/usr= /lib/pos=3D > > tgresql/8.1/bin >=20 > > is enough to reproduce the problem. With only --libdir, it works, and > > with only --bindir the test suite does not run at all because the > > postmaster cannot find $libdir (but that is still justifiable). >=20 > Try adding --datadir=3D/usr/lib/postgresql/8.1/share to that. Actually, > you'd be best off replacing all three options with > --prefix=3D/usr/lib/postgresql/8.1 > because that will make sure that the entire installation is consistent. When I only specify --prefix, it indeed works. However, it already breaks again with ./configure --prefix=3D/usr/share/postgresql/8.1 --exec-prefix=3D/usr/lib= /postgresql/8.1 I'm fine with dropping --bindir, --libdir, --datadir, but at least the arch-independent and arch-dependent prefix should work. I do not want to put all arch-independent data into /usr/lib, it would violate the FHS and Debian Policy. Is it possible to fix this? Thanks, Martin --=20 Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates?
Better path-matching for package relocatability (was Re: horology regression test failure)
From
Tom Lane
Date:
Martin Pitt <martin@piware.de> writes:
> Tom Lane [2005-12-20 16:39 -0500]:
>> We could doubtless improve make_relative_path to some extent, but the
>> mess you have above seems impossible to deal with. How is a mere
>> program supposed to deduce where things were moved to, given only
>> knowledge of the actual location of --bindir? I see little if any
>> pattern that would allow prediction of the corresponding --datadir,
>> let alone --libexecdir or --includedir ...
> Right, with make_relative_path's current approach that seems to be
> impossible. However, in a test suite I had expected a semantics like
> $DESTDIR, i. e. instead of mangling the path somewhere in the middle,
> the test suite should just prepend the tmp_check path.
Well, more generally what we need is a better match algorithm in
make_relative_path. After a few moment's thought I propose:
* Determine the common prefix of the compiled-in target_path and
bin_path (for typical cases this would be "/usr" or "/usr/local";
worst case is that the common prefix is just "/"). Call everything
to the right of the common prefix the "tail" of these paths. The
currently expected scenario is that the tails are "share" and "bin",
but there might be more than one directory level in them.
* Try to match the tail of the bin_path to the end of the actual binary
location (my_exec_path without the executable's name).
* If match, take everything to the left of the match in my_exec_path,
and append the tail of target_path to produce the result.
* If no match, use target_path as-is, same as now.
I think this would get right all of the cases the current code gets
right, and more generally would work when we need to substitute N
levels of directory names instead of just one. It may still be a
few bricks shy of a load, however. Any thoughts?
regards, tom lane
Am Mittwoch, 21. Dezember 2005 08:21 schrieb Martin Pitt: > However, if --bindir etc. cannot be set, then maybe configure should > not offer these options? They can be set and support for that will not go away. But if you choose unfortunate combinations of locations, the installation becomes unrelocatable. Having a relocatable installation is a fairly uninteresting feature for binary package building on Linux systems (it was mainly intended for Windows), so I would not worry about that. The problem with the temporary-installation regression tests has always been that they sometimes erroneously refer to the declared final installation location rather than the temporary installations. Rpaths have been a particular problem. This is something that one justs deals with manually. I suppose one could add, say, an environment variable override for the time zone database but I'm not sure that we need a global solution for such a rare failure case.
Peter Eisentraut <peter_e@gmx.net> writes:
> Am Mittwoch, 21. Dezember 2005 08:21 schrieb Martin Pitt:
>> However, if --bindir etc. cannot be set, then maybe configure should
>> not offer these options?
> They can be set and support for that will not go away. But if you choose
> unfortunate combinations of locations, the installation becomes
> unrelocatable. Having a relocatable installation is a fairly uninteresting
> feature for binary package building on Linux systems (it was mainly intended
> for Windows), so I would not worry about that.
It's not all that uninteresting, because "make check" is essentially an
instance of exercising the relocatability feature. The fact that things
like rpath might get in the way doesn't mean that we should ignore other
problems.
(I'm not sure about Debian's policy, but the RPMs do --disable-rpath for
unrelated policy reasons, so there shouldn't be any problem with
relocating an RPM-based installation...)
regards, tom lane
* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> (I'm not sure about Debian's policy, but the RPMs do --disable-rpath for
> unrelated policy reasons, so there shouldn't be any problem with
> relocating an RPM-based installation...)
Debian's policy is to do --disable-rpath also, which I hope Martin is
doing but honestly havn't gone back and checked on lately. :)
Thanks,
Stephen
Tom Lane wrote: > Well, more generally what we need is a better match algorithm in > make_relative_path. After a few moment's thought I propose: > > * Determine the common prefix of the compiled-in target_path and > bin_path (for typical cases this would be "/usr" or "/usr/local"; > worst case is that the common prefix is just "/"). Call everything > to the right of the common prefix the "tail" of these paths. The > currently expected scenario is that the tails are "share" and "bin", > but there might be more than one directory level in them. > > * Try to match the tail of the bin_path to the end of the actual binary > location (my_exec_path without the executable's name). > > * If match, take everything to the left of the match in my_exec_path, > and append the tail of target_path to produce the result. > > * If no match, use target_path as-is, same as now. > > I think this would get right all of the cases the current code gets > right, and more generally would work when we need to substitute N > levels of directory names instead of just one. It may still be a > few bricks shy of a load, however. Any thoughts? Sounds fine. When I did the original code, I was very conservative about where I would look in the fear I might hit something strange. Now that we have used this code in product with little problem, having it be more aggressive seems logical. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Hi! Stephen Frost [2005-12-21 21:06 -0500]: > * Tom Lane (tgl@sss.pgh.pa.us) wrote: > > (I'm not sure about Debian's policy, but the RPMs do --disable-rpath for > > unrelated policy reasons, so there shouldn't be any problem with > > relocating an RPM-based installation...) >=20 > Debian's policy is to do --disable-rpath also, which I hope Martin is > doing but honestly havn't gone back and checked on lately. :) Right, rpath is evil, and Debian packages have always disabled it. Merry christmas, Martin --=20 Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntulinux.org Debian Developer http://www.debian.org
Tom Lane wrote: > It's not all that uninteresting, because "make check" is essentially an > instance of exercising the relocatability feature. That just means that the test suite is testing features that are not of interest to certain groups of users; it doesn't declare a feature intesting. (Certainly the test suite failure should be fixed, but I don't consider making arbitary installations relocatable as necessary or restricting arbitrary installations as acceptable.) -- Peter Eisentraut http://developer.postgresql.org/~petere/
Martin Pitt <martin@piware.de> writes:
> I'm fine with dropping --bindir, --libdir, --datadir, but at least the
> arch-independent and arch-dependent prefix should work. I do not want
> to put all arch-independent data into /usr/lib, it would violate the
> FHS and Debian Policy.
> Is it possible to fix this?
I've committed changes to make_relative_path that should handle what
you want to do.
regards, tom lane
Hi Tom! =09 Tom Lane [2005-12-23 17:38 -0500]: > Martin Pitt <martin@piware.de> writes: > > I'm fine with dropping --bindir, --libdir, --datadir, but at least the > > arch-independent and arch-dependent prefix should work. I do not want > > to put all arch-independent data into /usr/lib, it would violate the > > FHS and Debian Policy. >=20 > > Is it possible to fix this? >=20 > I've committed changes to make_relative_path that should handle what > you want to do. This works just perfectly, nice christmas present. :) Thank you and have a nice day! Martin --=20 Martin Pitt http://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org In a world without walls and fences, who needs Windows and Gates?