Bug#774073: dh-make-perl: Ceating core module, install fails with "trying to overwrite foo which is also in bar"

[Damyan Ivanov]

-=| Niko Tyni, 30.12.2014 12:29:02 +0200 |=-
> On Mon, Dec 29, 2014 at 12:04:41AM +0000, Andrew Beverley wrote:
> > On Sun, 2014-12-28 at 14:51 +0200, Niko Tyni wrote:
> > > A more robust solution is using dpkg-divert in maintainer scripts to move
> > > the core version out of the way and then back later if necessary. See
> > > for instance the libmodule-corelist-perl package for an example
> > > implementation.
> > 
> > Okay, attached is a revised patch that does exactly that.
> 
> Nice, thanks for your work!
> 
> > It works (and it's taken me all day), but I admit that it's pretty
> > messy, so would welcome any feedback as to how to make this a little
> > tidier.
> 
> I think that it would be enough to only look for file conflicts in
> /usr/bin and perhaps in /usr/share/man as a first approximation. Other
> conflicts may merit manual attention and perhaps a --force-diverts switch
> or something like that.
> 
> I'm not sure if there are conflicting (heh) requirements here, with the
> "traditional" use of dh-make-perl geared for a base packaging that you're
> expected to tweak up to the quality and standards of Debian archive
> inclusion, and this --recursive use aiming for automatically generating
> packages suitable for local use without human attention.
> 
> But I don't really consider myself a dh-make-perl maintainer so
> I'll leave judgement on that to those in the team who do.
> Perhaps it's as easy as changing defaults for other options (like the
> --force-diverts above) based on the --recursive flag.

I think handling core modules with conflicts makes sense. We don't 
stumble upon such cases but the code would be useful when we do (and 
obviously it has its uses as part of the --recursive path).

> > I figured that the dpkg-divert lines have to be generated during build,
> > otherwise it's not easily known which files will be installed.
> 
> It would be nice to not generate the maintainer scripts at all in the
> common case where they aren't needed.
> 
> Also, generating them in the source debian/ directory first and including
> the #DEBHELPER# marker in them would be cleaner and enable debhelper
> to replace the marker with any magic it considers necessary when it
> installs them into the DEBIAN/ binary package directory. (See debhelper(7)
> and dh_installdeb(1))

I concur with Niko here. Build-time maintainer scripts juggling sounds 
bad. What I'd try is see if there are possibly conflicting files in 
/usr/bin (plus manpages) and if there are, create the relevant 
.preinst and .postrm maintainer scripts, borrowing from e.g. 
libmodule-build-perl, perhaps changing the version comparison with 
a call to dpkg-divert --list.


-- dam