From owner-freebsd-ports-bugs@FreeBSD.ORG Fri Nov 4 09:00:33 2005 Return-Path: X-Original-To: freebsd-ports-bugs@hub.freebsd.org Delivered-To: freebsd-ports-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 3D42F16A41F for ; Fri, 4 Nov 2005 09:00:33 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0066F43D66 for ; Fri, 4 Nov 2005 09:00:28 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id jA490S7f099382 for ; Fri, 4 Nov 2005 09:00:28 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id jA490SG5099381; Fri, 4 Nov 2005 09:00:28 GMT (envelope-from gnats) Date: Fri, 4 Nov 2005 09:00:28 GMT Message-Id: <200511040900.jA490SG5099381@freefall.freebsd.org> To: freebsd-ports-bugs@FreeBSD.org From: "Thomas E. Zander" Cc: Subject: Re: ports/87853: [fix] multimedia/mplayer: no bsdbt848 driver compiled in X-BeenThere: freebsd-ports-bugs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Thomas E. Zander" List-Id: Ports bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Nov 2005 09:00:33 -0000 The following reply was made to PR ports/87853; it has been noted by GNATS. From: "Thomas E. Zander" To: Simun Mikecin Cc: bug-followup@FreeBSD.org, Edwin Groothuis Subject: Re: ports/87853: [fix] multimedia/mplayer: no bsdbt848 driver compiled in Date: Fri, 4 Nov 2005 09:50:42 +0100 --UPT3ojh+0CqEDtpF Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Hi, > So, my conclusion is: on the architectures that have > their "machine" version of ioctl_bt848.h (and those > are alpha, i386 and pc98), those "machine" version > files get installed as > /usr/include/machine/ioctl_bt848.h. > But *ALL* architectures get > /usr/include/dev/bktr/ioctl_bt848.h installed. omg...I see where this (sorry) crap is leading us to. Don't worry, I understand your problem and this is certainly needed to be handled. I also didn't intend to refuse any change to the port, it is just that I can't approve to this particular pr which only means that we have to modify it. Despite the fact that it is really a horrible situation to have a different include base for these two (very similar!) architectures in the same release, there is another problem which forbids to just replace the location of ioctl_bt848.h We have to address this depending on ${OSVERSION} because RELENG_4 still should be supported by the ports which allow us to do so and this branch iirc only knows /usr/include/machine/ioctl_bt848.h! So I suggest that we proceed as follows: - drop the xmms and cdrom/dvdrom patches your pr is covering as we do this already in post-patch: - don't replace the location of this header in the configure script, instead extend it by something like: ... #elif (__FreeBSD__ >= 5) #include ... If you're okay with that, I'll prepare a diff and see that it gets committed. Regards, Riggs P.S. For the record: Finally it gets a mess to maintain ports like this one if there is nothing you can really rely on. I don't have enough boxes to genuinely check everything on every architecture for every RELENG_*. I don't have a RELENG_4 box, no amd64, no ia64, no sparc and so on. Still a port maintainer should support every officially supported branch (RELENG_4-7 !!) on every machine and as we see from time to time, they *do* differ which makes it completely impossible for a maintainer to reproduce all the problem a user might have with a specific version or branch. This is definitely *not* an issue to be handled sloppily. Edwin, maybe you could discuss this problem with some src committers some time before things get worse... --UPT3ojh+0CqEDtpF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- iD8DBQFDayDijdSJKchZls0RAun0AJ9CailDPWWm0av2ALZgkpRd/IMKqgCfTTCq 02ZmrrHL0ed7MU6Ti6fCGSc= =b/nE -----END PGP SIGNATURE----- --UPT3ojh+0CqEDtpF--