Bug 37596 - EMACS_PORT_NAME=xemacs21 forks make infinitely when installing other ports
Summary: EMACS_PORT_NAME=xemacs21 forks make infinitely when installing other ports
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: Port Management Team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-04-30 14:30 UTC by Jay Sachs
Modified: 2006-01-28 02:12 UTC (History)
0 users

See Also:


Attachments
use_emacs.patch (75.90 KB, patch)
2005-07-25 09:01 UTC, Sergey Matveychuk
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jay Sachs 2002-04-30 14:30:01 UTC
If EMACS_PORT_NAME is set to xemacs21, installing ports fails when
registering the installation. The system forks into infinite
regress. I managed to get up to load 18, and by the time 'top' came
back with a display, it was filled with identical 'make' processes
invoked as:

   make CHILD_DEPENDS=yes PARENT_CHECKED= package-depends-list

Fix: 

Don't set EMACS_PORT_NAME. But then the ports want to install "plain
old" emacs.
How-To-Repeat: 
1. Install xemacs21 from ports.
2. Set EMACS_PORT_NAME=xemacs21 in /etc/make.conf
3. Try to install, e.g. portupgrade from ports. This happens with other ports too (e.g. xslide).

The "infinite make fork" occurs when "Registering install for ...". The installation actually occurs, but no files are written to /var/db/pkg/[portname].
Comment 1 Sheldon Hearn 2003-02-05 18:44:11 UTC
Hi folks,

I'd just like to confirm that I see the same behaviour on a fresh
5.0-CURRENT box (just upgraded from a fresh 5.0-RELEASE) and a fresh
ports tree with nothing in /etc/make.conf other than

	EMACS_PORT_NAME?=	xemacs21

Ciao,
Sheldon.
Comment 2 Sheldon Hearn freebsd_committer freebsd_triage 2003-02-07 13:28:14 UTC
Responsible Changed
From-To: freebsd-ports-bugs->shige

Over to maintainer.
Comment 3 Mark Linimon freebsd_committer freebsd_triage 2004-12-23 19:03:06 UTC
State Changed
From-To: open->feedback

Is this still a problem with recent versions? 


Comment 4 Mark Linimon freebsd_committer freebsd_triage 2004-12-23 19:03:06 UTC
Responsible Changed
From-To: shige->freebsd-ports-bugs

Maintainer was reset.
Comment 5 Mark Linimon freebsd_committer freebsd_triage 2004-12-23 19:30:55 UTC
State Changed
From-To: feedback->closed

Submitter's email address bounces.
Comment 6 Sergey Matveychuk freebsd_committer freebsd_triage 2005-05-12 12:37:33 UTC
State Changed
From-To: closed->open

I'll care 


Comment 7 Sergey Matveychuk freebsd_committer freebsd_triage 2005-05-12 12:37:33 UTC
Responsible Changed
From-To: freebsd-ports-bugs->sem

Reopen as still actual
Comment 8 Sergey Matveychuk freebsd_committer freebsd_triage 2005-06-15 08:26:56 UTC
State Changed
From-To: open->closed

- POLA violated bsd.emacs.mk should be rewritten
Comment 9 Mark Linimon freebsd_committer freebsd_triage 2005-07-24 20:34:37 UTC
State Changed
From-To: closed->suspended

With bugmeister hat on, change this from 'closed' to 'suspended' because 
from what I can determine, the problem still exists, but a solution is 
being being consider but being delayed until after 6.0 is out.
Comment 10 Sergey Matveychuk freebsd_committer freebsd_triage 2005-07-25 09:01:10 UTC
-- 
Sem.
Comment 11 Sergey Matveychuk freebsd_committer freebsd_triage 2005-07-25 09:27:25 UTC
State Changed
From-To: suspended->open

Reopen and assign to portmgr as affected on bsd.port.mk 


Comment 12 Sergey Matveychuk freebsd_committer freebsd_triage 2005-07-25 09:27:25 UTC
Responsible Changed
From-To: sem->portmgr

Reopen and assign to portmgr as affected on bsd.port.mk
Comment 13 Mark Linimon freebsd_committer freebsd_triage 2006-01-21 19:58:20 UTC
State Changed
From-To: open->analyzed

An updated patch based on this has been accepted for a test build on the 
cluster.
Comment 14 Mark Linimon freebsd_committer freebsd_triage 2006-01-28 02:12:17 UTC
State Changed
From-To: analyzed->closed

Committed, thanks.