From owner-freebsd-emulation@FreeBSD.ORG Fri Feb 10 12:27:26 2006 Return-Path: X-Original-To: freebsd-emulation@FreeBSD.org Delivered-To: freebsd-emulation@FreeBSD.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DA9FE16A420; Fri, 10 Feb 2006 12:27:26 +0000 (GMT) (envelope-from laszlof@vonostingroup.com) Received: from ritamari.vonostingroup.com (ritamari.vonostingroup.com [216.144.193.230]) by mx1.FreeBSD.org (Postfix) with ESMTP id B76EC43D55; Fri, 10 Feb 2006 12:27:24 +0000 (GMT) (envelope-from laszlof@vonostingroup.com) Received: from c-71-227-92-22.hsd1.mi.comcast.net ([71.227.92.22] helo=[192.168.0.6]) by ritamari.vonostingroup.com with esmtpa (Exim 4.60 (FreeBSD)) (envelope-from ) id 1F7XNF-00019m-0A; Fri, 10 Feb 2006 07:27:41 -0500 Message-ID: <43EC86B4.6060600@vonostingroup.com> Date: Fri, 10 Feb 2006 07:27:32 -0500 From: "Frank J. Laszlo" User-Agent: Thunderbird 1.5 (X11/20060123) MIME-Version: 1.0 To: Alexander Leidinger References: <200602081940.k18Je7uC012039@freefall.freebsd.org> <20060209202602.1449abba.jylefort@FreeBSD.org> <20060210101931.k017bqbpus8gosws@netchild.homeip.net> In-Reply-To: <20060210101931.k017bqbpus8gosws@netchild.homeip.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ritamari.vonostingroup.com X-AntiAbuse: Original Domain - freebsd.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [26 6] X-AntiAbuse: Sender Address Domain - vonostingroup.com X-Source: X-Source-Args: X-Source-Dir: Cc: Jean-Yves Lefort , freebsd-emulation@FreeBSD.org Subject: Re: ports/91911: [PATCH]: x11-toolkits/linux-gtk2: distfile unfetchable X-BeenThere: freebsd-emulation@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Development of Emulators of other operating systems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2006 12:27:27 -0000 Alexander Leidinger wrote: > Jean-Yves Lefort wrote: > >>> Let me guess: you are trying to install acroread7 while linux-gtk2 >>> isn't installed. >>> >>> You get this error message because of a bug in bsd.port.mk (or in the >>> acroread7 port, depending on your point of view...). >>> >>> The linux-gtk2 port is just fine. Install it by hand instead of a >>> dependency of the acroread port and it should work just fine. >> >> Alexander, as you've been told many times now the acroread7 port is >> fine (with regard to that issue at least); the bug is in bpm or in the >> linux ports which override ARCH. I suggest to commit Frank Laszlo's >> patches, since modifying bpm is a tedious process. > > I don't doupt that bpm has a problem in this case. And I agree that we > may be > able to come up with a better solution for the linux ports. But I > don't agree > that the acroread port is fine. It doesn't fit into the way most of > the linux > ports work ATM, so it doesn't play well with the rest, so it's broken > in this > regard. So the short-time fix for the acroread port would be to add > the same > ARCH shuffling as the other ports have (see below). > Just because all the other linux ports do this, doesn't make it right, and modifying a read-only variable is only asking for trouble down the line. > Yes, the use of a different variable name in the linux ports is a > better fix > for this. No, I don't want to commit Frank's patches. Not because they > are > blatantly wrong, but because I don't agree with the name of the variable > used. SUB_ARCH is very generic, while your use of LINUX_RPM_ARCH in > bsd.linux-rpm.mk looks much better. Whats wrong with SUB_ARCH? (Substitute ARCH) And if the functionality for this is allready in bsd.linux-rpm.mk, why dont we use it? (I just noticed the code there myself) Theres no point is re-writing code thats allready implemented. > > > If someone comes up with a patch which changes all linux ports which > do the > ARCH-shuffling thing to use LINUX_RPM_ARCH instead, I try to get time and > commit this (after coordinating with portmgr because of the > "no-sweeping-changes flag"). I also don't mind if someone else commits > such > patches (after coordinating with portmgr). I'd be more than happy to modify my patches to do this. I have included ALL the ports that toy with ARCH, at least the linux specific ones. And I will also contact portmgr to coordinate the testing. > > But I don't think we need to rush this out before the ports freeze. It > would > be enough to commit the ARCH-shuffling part to the acroread port and > let the > RELEASEs ship with it. After the ports freeze it could then be fixed > properly > without time pressure. acroread7 will not build for most people on amd64. I think this is a pretty darn good reason to rush the fixes out. > > It's not only about doing it right, it's also about time constraints and > about not breaking things for our userbase (or new users of the upcoming > release). And it's not only about time constraints of those committers, > which are willing to handle it (and have time to fix bugs in case some > slip > into the commit), but also about project related time constraints > (release > related freezes, maybe portmgr want's to do a experimental run of those > patches on the cluster, ...). The update to the current linux_base > version > was done shortly before a release, and kris and I spend the days around > christmas to get it into a good shape. The update was necessary > because of > security issues, and I think my time was spend well at that time, > since we > where able to ship with a usable linuxolator (I don't remember any major > bugs, and I changed a lot of ports). The change both of you propose > has an > impact on a lot of ports (because of the use of the linux-gtk Makefile > in a > lot of other ports), and I don't think we absolutely need to do such a > sweeping change before the release since there not such a heavy wight > reason > like we had with the linux_base update. There's an easy and small > work-around > for the acroread port available and it doesn't hurt to commit it, so > there's > no need to force the inclusion of the "architecturally(sp?) right fix". > > Bye, > Alexander. > This is why we need to have people test the patches before we do anything. I'll get on this later today and get back with you all. Regards, Frank