Bugzilla Bug 191748

I had net-misc/dhcp-3.0.3-r9 installed and working correctly, with outstanding
leases recorded in /var/lib/dhcp/dhcpd.leases.  I ran 'emerge dhcp', which
attempted to merge net-misc/dhcp-3.1.0.  According to the release notes (found
in file RELNOTES in the tarball), 'make install' now creates a
/var/lib/dhcp/dhcpd.leases if one does not exist.  Since Portage installs the
package into a staging area prior to live merging, the 'make install' phase of
the dhcp build process will never see a dhcpd.leases file, and will always
create one.  This results in an empty ${D}/var/lib/dhcp/dhcpd.leases. 
Unfortunately, old versions of the dhcp 'make install' process did *not* create
such a file, so the file ${ROOT}/var/lib/dhcp/dhcpd.leases is considered not to
be owned by any package.  This causes Portage to abandon the merge process:

* checking 42 files for package collisions
existing file /var/lib/dhcp/dhcpd.leases is not owned by this package
* This package is blocked because it wants to overwrite
* files belonging to other packages (see messages above).
* If you have no clue what this is all about report it
* as a bug for this package on http://bugs.gentoo.org

package net-misc/dhcp-3.1.0 NOT merged


Searching all installed packages for file collisions...
Press Ctrl-C to Stop

None of the installed packages claim the above file(s).


I worked around this by moving ${ROOT}/var/lib/dhcp/dhcpd.leases to a temporary
name, emerging dhcp, and then moving the temporary name back into place.

It would be nice if the ebuild could work around the merge collision, or at
least display a warning that this would occur.  Based on my reading of
portage.py, the collision check occurs before pkg_preinst, so the diagnostic
would need to be done in src_install, which is less than ideal since
src_install could be run as part of an 'emerge --buildpkgonly dhcp', which may
occur on a different system than where the package would actually be installed.

A possible workaround for this problem would be to add this block to the
src_install phase:

if [ -e ${ROOT}/var/lib/dhcp/dhcpd.leases ]; then
        rm -f ${D}/var/lib/dhcp/dhcpd.leases
fi

This would avoid the merge collision for users who upgrade from a previous
version of dhcp, but allow users who are installing fresh to have
/var/lib/dhcp/dhcpd.leases listed in the package's CONTENTS file.  As above, it
would only work for users who had the same dhcp layout on the build host and
the installation host, which hopefully covers the vast majority of users.

(In reply to comment #0)
> A possible workaround for this problem would be to add this block to the
> src_install phase:
> 
> if [ -e ${ROOT}/var/lib/dhcp/dhcpd.leases ]; then
>         rm -f ${D}/var/lib/dhcp/dhcpd.leases
> fi

Rather in pkg_preinst. ${ROOT} can't be safely used in src_*.

(In reply to comment #1)
> Rather in pkg_preinst. ${ROOT} can't be safely used in src_*.

OK, I did not know that.  However, as I noted in comment #0, the Portage source
states that pkg_preinst will be run after the collision check.  From the
description of portage.py:treewalk():

        This function does the following:

        Collision Protection.
        calls doebuild(mydo=pkg_preinst)
        Merges the package to the livefs
        ...

Portage aborts during the collision protection phase, so it will never reach
pkg_preinst.

(In reply to comment #0)
> A possible workaround for this problem would be to add this block to the
> src_install phase:
> 
> if [ -e ${ROOT}/var/lib/dhcp/dhcpd.leases ]; then
>         rm -f ${D}/var/lib/dhcp/dhcpd.leases
> fi

No need to check $ROOT here, fixed.