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

Package:
dh-make-perl
Source:
dh-make-perl
Submitter:
Andy Beverley
Date:
2015-09-26 16:03:06 UTC
Severity:
normal
#774073#5
Date:
2014-12-28 12:19:32 UTC
From:
To:
When creating an updated version of a module that is already in core,
the subsequent install fails (as expected) with a message such as:
"trying to overwrite '/usr/bin/instmodsh', which is also in package
perl 5.14.2-21+deb7u2".

Given that dh-make-perl has to be forced into creating core modules,
I think it's appropriate to instruct dpkg that the package contains
files that replace the core module. This patch does so.

If you think it's more appropriate, I'd be happy to create a further
doc patch and/or another command line option to go with this patch.
#774073#10
Date:
2014-12-28 12:38:43 UTC
From:
To:
#774073#15
Date:
2014-12-28 12:29:30 UTC
From:
To:
Forgot to say, this patch relies on the patch in #774074
#774073#20
Date:
2014-12-28 12:51:39 UTC
From:
To:
Please note that a "Replaces" entry isn't quite enough for packages with
conflicting files to coexist cleanly: in case the replacing package
gets removed later, the conflicting file would then be gone from the
system altogether.

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.
#774073#25
Date:
2014-12-28 15:57:22 UTC
From:
To:
Good point, I hadn't thought of that.

Thanks for the example. I'm currently thinking of this as a solution,
but wondering whether there is an easier way?

1. Check if the module is provided by core
2. If so, check which files in the new package are already in core
3. For each of those files, generate a dpkg-divert line

In the case of a large module, there could be several dozen dpkg-divert
lines, but I can't see a better way of doing it?

Thanks,

Andy
#774073#30
Date:
2014-12-29 00:04:41 UTC
From:
To:
Okay, attached is a revised patch that does exactly that.

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 figured that the dpkg-divert lines have to be generated during build,
otherwise it's not easily known which files will be installed.

Comments welcome!
#774073#35
Date:
2014-12-30 10:29:02 UTC
From:
To:
Nice, thanks for your work!

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.

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))
#774073#40
Date:
2015-05-23 15:10:01 UTC
From:
To:
-=| Niko Tyni, 30.12.2014 12:29:02 +0200 |=-

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 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.
#774073#45
Date:
2015-09-26 15:55:05 UTC
From:
To:
I'm having another look at this, but I have some memory fade. Does anyone
know why I put rules.dh.core in debian/ rather than share/ ?

Which one should it be in?

Thanks,

Andy
#774073#50
Date:
2015-09-26 15:55:05 UTC
From:
To:
I'm having another look at this, but I have some memory fade. Does anyone
know why I put rules.dh.core in debian/ rather than share/ ?

Which one should it be in?

Thanks,

Andy