Bug 30576 - java/jdk13 attempts to build even if one of it's deps fails.
Summary: java/jdk13 attempts to build even if one of it's deps fails.
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: java (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-09-14 20:30 UTC by quik
Modified: 2003-07-21 23:20 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description quik 2001-09-14 20:30:00 UTC
the native jdk1.3 depends upon the linux version but because the port for the linux version requires the user to manually fetch some files, the port (for the linux version) simply displays a message informing the user about where to obtain these files and exits but does not return an error code so when the native jdk13 port tries to build the linux one, it keeps going after the build fails and then fails itself too.

Fix: 

The linux version of the port should return an error code that signifies failure if it does not have the requisite files in /usr/ports/distfiles.
How-To-Repeat: try to build java/jdk13 on a box that has never had the linux version of jdk13 built or installed on it.
Comment 1 Pete Fritchman freebsd_committer freebsd_triage 2001-10-05 08:11:35 UTC
Responsible Changed
From-To: freebsd-ports->sobomax

Over to maintainer; but this looks like more of a general problem too.
Comment 2 Maxim Sobolev freebsd_committer freebsd_triage 2002-08-30 13:27:00 UTC
Responsible Changed
From-To: sobomax->glewis

Over to maintainer.
Comment 3 Greg Lewis freebsd_committer freebsd_triage 2003-07-21 18:22:55 UTC
Responsible Changed
From-To: glewis->portmgr

I've worked around this issue for the particular port mentioned, 
but as one of the notes states "this looks like more of a general 
problem too". 

Hence I'm reassigning to portmgr to see if they consider it to be 
a general problem.  The problematic scenario is as follows: 

. Port A uses the IGNORE variable to indicate that the distfile 
must be fetched by hand (for example). 
. Port B depends on port A (to build, for instance). 
. Building port B without port A installed will do the following: 

. Try to build port A but "fail" and spit out IGNORE message. 
Unfortunately this produces a 0 exit status and... 
. Continue with build of port B until an unexpected failure 
occurs. 

The build should really halt after the first step since 
continuing on obfuscates the reason for the failure. 

Maybe this is just an abuse of the IGNORE variable and there is 
already a better way to do this?  If so please let me know and 
I'll fix the offending jdk ports.  If not it would probably be 
worthwhile creating a way to do this.
Comment 4 Kris Kennaway 2003-07-21 22:27:39 UTC
On Mon, Jul 21, 2003 at 10:30:46AM -0700, Greg Lewis wrote:

>   . Try to build port A but "fail" and spit out IGNORE message.
>     Unfortunately this produces a 0 exit status and...

IGNORE probably just needs to set a non-zero exit status.

Kris
Comment 5 Greg Lewis freebsd_committer freebsd_triage 2003-07-21 23:16:21 UTC
State Changed
From-To: open->closed

IGNORE does now cause the port build to exit with a non-zero status 
when its being built as a dependency.
Comment 6 Greg Lewis 2003-07-21 23:23:14 UTC
On Mon, Jul 21, 2003 at 02:27:39PM -0700, Kris Kennaway wrote:
> On Mon, Jul 21, 2003 at 10:30:46AM -0700, Greg Lewis wrote:
> 
> >   . Try to build port A but "fail" and spit out IGNORE message.
> >     Unfortunately this produces a 0 exit status and...
> 
> IGNORE probably just needs to set a non-zero exit status.

Oops, further investigation indicates that it now does when the package
is being built as a dependency.  Sorry!  I'll close the PR.

-- 
Greg Lewis                          Email   : glewis@eyesbeyond.com
Eyes Beyond                         Web     : http://www.eyesbeyond.com
Information Technology              FreeBSD : glewis@FreeBSD.org