Date: Thu, 9 Aug 2007 22:07:18 +0100 From: RW <fbsd06@mlists.homeunix.com> To: freebsd-ports@freebsd.org Subject: Re: Portmaster and Portmanager problem with jdk15 Message-ID: <20070809220718.5ddf3bb9@gumby.homeunix.com.> In-Reply-To: <1186677666.76028.28.camel@rnoland-ibm.acs.internap.com> References: <20070807205138.6c5759d6@gumby.homeunix.com.> <46B8D605.2060008@FreeBSD.org> <1186520349.1257.58.camel@rnoland-ibm.acs.internap.com> <20070809154758.GA42925@misty.eyesbeyond.com> <1186677666.76028.28.camel@rnoland-ibm.acs.internap.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 09 Aug 2007 12:41:06 -0400
Robert Noland <rnoland@2hip.net> wrote:
> On Thu, 2007-08-09 at 09:47 -0600, Greg Lewis wrote:
> > On Tue, Aug 07, 2007 at 04:59:09PM -0400, Robert Noland wrote:
> > > On Tue, 2007-08-07 at 13:28 -0700, Doug Barton wrote:
> > > > RW wrote:
> > > > > Both Portmaster and Portmanager (I haven't tried Portupgrade)
> > > > > install java/linux-sun-jdk15 on an upgrade of java/jdk15. If
> > > > > I upgrade jdk15 manually it isn't built, so it must be done
> > > > > by the tools.
> > > > >
> > > > > The way the jdk15 makefile works is that it looks for the
> > > > > location of an existing jdk installation for bootstrapping
> > > > > and sets BOOTSTRAPJDKDIR accordingly. We then have:
> > > > >
> > > > > # if no valid jdk found, set dependency
> > > > > .if !defined(BOOTSTRAPJDKDIR)
> > > > > BOOTSTRAPJDKDIR?=${LOCALBASE}/linux-sun-jdk${SUN_LINUX_JDK_VERSION}
> > > > > .endif
> > > > > BUILD_DEPENDS+=${BOOTSTRAPJDKDIR}/bin/javac:${PORTSDIR}/java/linux-sun-jdk15
> > > > >
> > > > >
> > > > > I don't know why this causes the build-tools to install
> > > > > linux-sun-jdk15, but simply moving the BUILD_DEPENDS+= line
> > > > > inside the if-endif block, seems to fix the problem. That
> > > > > line is only needed if no jdk is present.
> > > >
> > > > Your analysis sounds right.
> > >
> > > Almost, doing this will remove the dependency on linux-sun-jdk15
> > > if another bootstrap is installed, but it won't add one for the
> > > installed bootstrap. Currently, it will always have a dependency
> > > on linux-sun-jdk15 even if another bootstrap jdk is installed.
> > > jdk14 also has this issue.
> >
> > So, while the dependency being generated is bogus, I'm not quite
> > sure why its having the effect that you mention. The port is
> > trying to figure out which bootstrap it should use out of a list of
> > candidates and, when it has figured this out, create a "dependency"
> > on it. The dependency is (often) bogus, but that shouldn't
> > actually have the effect your seeing as I understand it. In the
> > case where the bootstrap already exists, the dependency shouldn't
> > be installed as I understand it since the check for that path will
> > succeed, unless portmaster and portmanager decide to do their own
> > proactive installation of dependencies based on the port? In the
> > case where the bootstrap doesn't exist then the dependency will be
> > the correct default bootstrap and should be installed.
>
> As it stands, the jdk14 and jdk15 ports register a static dependency
> on the default bootstrap unconditionally. Portmanager ( I assume
> portmaster behave similarly ) parses the Makefiles for all installed
> ports so that it can take environment settings and options into
> account and then handles the building of each port separately. In
> the case of the jdk ports, it always sees a dependency on the default
> bootstrap. This means that the default bootstrap must be installed
> and current before it will update the jdk ports, even if it is a
> rebuild which may be bootstrapped by itself.
It's a little irritating that Portmanager does that because I've
seen it go back and rebuild a port it's already built in order for it
to pick-up a possible new run dependency. By comparison with that the
indiscriminate building of this bootstrap port is pretty crude.
I don't think the handling of build-dependencies was left in a very
good state when Michael Shultz departed, you only have to look at the
way it handles bison conflicts.
> The proposed patch above, does resolve this issue, however it doesn't
> allow for an accurate dependency registration of the bootstrap that
> was actually used to build the port.
Maybe something has changed, but I thought that only library and
run dependencies were supposed to be registered.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070809220718.5ddf3bb9>