gregor herrmann wrote:
> When using dh7 and the nice small debian/rules files for perl modules
> I saw several times that stuff gets installed into /usr/usr with
> dh_auto_install.
>
> Today I again stumbled over this phenomenon -- with
> libdata-serializer-perl, in the pkg-perl repo.
>
> After some investigation (and looking at other modules) it seems that
> the problem comes up with modules where Makefile(.PL) is just a
> wrapper for Module::Build; in the case of libdata-serializer-perl
> dh_auto_install calls
> make install
> DESTDIR=/tmp/buildd/libdata-serializer-perl-0.48/debian/libdata-serializer-perl
> PREFIX=/usr
> which is perfectly fine but the previously generated Makefile then
> calls
> /usr/bin/perl Build --makefile_env_macros 1 install
> which AFAICS adds the "PREFIX=/usr" to "perl Build" -- and so we end
> up with files in
> /tmp/buildd/libdata-serializer-perl-0.48/debian/libdata-serializer-perl/usr/usr/
>
> I'm not sure if and what debhelper can do about it; one option might
> be to prefer Build(.PL) over Makefile(.PL) for
> dh_auto_{configure,build,install}
> (or at least _install); in general I prefer MakeMaker over
> Module::Build magic, but in this case it would solve the problem.Changing it to prefer Build.PL is dangerous, because: * An unknown number of packages may be using dh and have both a Makefile.PL and a Build.PL, and some subset of those may fail when the Build.PL is used. No way to know w/o testing. * A package may ship a Makefile that calls Build.PL, but also does other things. Prefering Build.PL would break such a package. Maybe such packages don't currently exist, but they could in future, and if the change were made, they couldn't easily use dh. Instead I think dh_auto_install should get an improved check for whether a Makefile was generated by MakeMaker, and only do the prefix hack if that is clearly the case. -- see shy jo
signature.asc
Description: Digital signature
