When make release fetches distfiles for the documentation ports before entering the chroot, the checksum-recursive command can fail if there are conflicting ports installed on the build system. For example: ===> ghostscript8-nox11-8.71_5 conflicts with installed package(s): ghostscript8-8.71_5 They install files into the same place. Please remove them first with pkg_delete(1). *** Error code 1 This isn't really a problem though, because the make release ports will be built in the chroot and won't conflict with what's in /usr/local Fix: Add -DDISABLE_CONFLICTS to checksum-recursive commands Patch attached with submission follows: How-To-Repeat: install print/ghostscript8 (make sure WITHOUT_X11 is not set) run make release
Responsible Changed From-To: freebsd-bugs->freebsd-ports-bugs misfiled ports PR
Responsible Changed From-To: freebsd-ports-bugs->doceng Over to maintainer (via the GNATS Auto Assign Tool)
This is not a misfiled ports PR; it is a src PR regarding "make release" in /usr/src/release (ie building ISO images of FreeBSD's base system). It should be assigned to re@freebsd.org or someone similar. -- Rob Farmer
On 09/04/10 23:10, Rob Farmer wrote: > This is not a misfiled ports PR; it is a src PR regarding "make > release" in /usr/src/release (ie building ISO images of FreeBSD's base > system). It should be assigned to re@freebsd.org or someone similar. > 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!
On Sun, Sep 5, 2010 at 10:15, <vwe@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
back to pool
Is this PR still relevant?