Re: ports/150265: [patch] print/ghostscript8 disable bogus port conflicts in make release

On Sun, Sep 5, 2010 at 10:15,  <vwe_at_freebsd.org> wrote:
>
> Rob,
>
> IMO the question is not if the problem _can_ be solved in the base build
> system. I doubt you'll find many src committers willing to break other
> peoples machines by using DISABLE_CONFLICTS as a general problem solver.
>
> It may well work for your machine and you're free to do that.
>
> The maintainer of ghostscript8 may check the issue but is free to close the
> PR as WONTFIX (I suspect that will most likely happen).
>
> Instead of filing a PR for such problems, a discussion on our fine mailing
> lists might be good.
>
> Thanks!
>

[adding a mailing list per your suggestion]

I think you are misunderstanding the issue here.

This is not a ghostscript issue and the maintainer of ghostscript
isn't the right person to look at it. The same issue can appear with
other ports used by make release, such as perl. In fact, there isn't
any way for this to be solved in the ports tree short of removing the
CONFLICTS handling (which is not what I am suggesting).

What happens is the release building process uses certain ports to
generate the HTML documentation (release notes, etc.) on the CDs. To
insure a clean build environment, these ports are built and installed
in a chroot away from the main system. However, prior to entering the
chroot, the distfiles for these ports are fetched and checksummed with
"make checksum-recursive". This process occurs outside the chroot, so
the ports system looks for conflicts with what is installed in
/usr/local, assuming that these distfiles are for ports to be
installed in /usr/local.

This assumption is flawed, since they will not be installed there and
thus will not conflict. My patch runs the "make checksum-recursive"
target with -DDISABLE_CONFLICTS to avoid these false positives.

This will not "break other people's machines" as you state because the
absolute worst case scenario with my patch is having a couple
duplicate distfiles (such as perl5.10 and perl5.12). Nothing is built
or installed with the DISABLE_CONFLICTS flag.

What I'm asking you to do is revert the description, category, and
assignment of the PR so that someone who is familiar with the release
building process will see it.

-- 
Rob Farmer