From owner-freebsd-ports@FreeBSD.ORG Mon Jan 29 10:28:05 2007 Return-Path: X-Original-To: ports@freebsd.org Delivered-To: freebsd-ports@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 75AFB16A402; Mon, 29 Jan 2007 10:28:05 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 025D513C442; Mon, 29 Jan 2007 10:28:04 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A5D5E9.dip.t-dialin.net [84.165.213.233]) by redbull.bpaserver.net (Postfix) with ESMTP id 936082E18F; Mon, 29 Jan 2007 11:38:41 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id 3F2235B4873; Mon, 29 Jan 2007 11:27:53 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.13.8/8.13.8/Submit) id l0TARqi4048682; Mon, 29 Jan 2007 11:27:52 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from psbru.cec.eu.int (psbru.cec.eu.int [158.169.131.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 29 Jan 2007 11:27:52 +0100 Message-ID: <20070129112752.obix02qpk44wgo4o@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 29 Jan 2007 11:27:52 +0100 From: Alexander Leidinger To: Andrew Pantyukhin References: <20070128193804.5b2e09ba@Magellan.Leidinger.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.3) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-14.864, required 6, autolearn=not spam, BAYES_00 -15.00, DK_POLICY_SIGNSOME 0.00, FORGED_RCVD_HELO 0.14) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: FreeBSD Ports Subject: Re: Non-daemon programs requiring kernel modules X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jan 2007 10:28:05 -0000 Quoting Andrew Pantyukhin (from Sun, 28 Jan =20 2007 21:58:28 +0300): > On 1/28/07, Alexander Leidinger wrote: >> Quoting "Andrew Pantyukhin" (Sun, 28 Jan =20 >> 2007 18:35:30 +0300): >> >>> I'm porting a simple util requiring aio(4). My plan is >>> to install a wrapper script which includes rc.subr(8) >>> and uses its required_modules mechanism. >>> >>> If anyone has a better idea, please tell me. >> >> Just tell at port/package install time the requirement. Every linux >> program needs the linux module or the corresponding kernel option. If >> the code is not available at runtime, the user will get an error. Unix >> is not for dumb people, so I don't think we need this low-level >> hand-holding. > > That's one opinion. But Unix is also not about dumb > developers. As a ports developer, my job is to make > it easier for users to run third-party software and > that's just what I'm trying to do to the extent of > my skills and motivation... I agree, but if you are interested in a general solution, how do you =20 want to apply it to the linux stuff? I see the problem, that if you try to do a generic solution, users =20 want it for the linux stuff too. There's not problem with such a =20 request from a high level point of view, but technically I don't see =20 how this can be done in a reasonable way for the linux stuff. For =20 acroread or skype, we could do it very easy (there are already FreeBSD =20 shell scripts as wrappers, so we could check with "kldstat -v | grep =20 linux"), but users would expect something like this in a lot more =20 places then. In some places you just can not do it, because those =20 programs are also used by linux stuff internally or can be used in a =20 chroot. It's like using a program which issues some ioctls which are =20 valid for SCSI devices, but not ata devices (or vice versa). Or if you =20 want to use SYSVSHM and it isn't available in the kernel. The user =20 will get an error message because he did the wrong thing. I think it is more POLA to keep it this way, instead of doing it for =20 some stuff but not all stuff. If we are able to do it for all stuff, =20 great, go ahead, but in this case I don't think it is a good idea. You can bail out in the port/package if aio is not available. You can =20 parse the output of "kldstat -v" and determine if aio is compiled into =20 the kernel or loaded as a module. If it is loaded as a module, check =20 if it is enabled in loader.conf. If this is not the case, fail to =20 install/build with a suitable message. This is (more or less) how we =20 do it in the linux ports. Bye, Alexander. --=20 Some primal termite knocked on wood. And tasted it, and found it good. And that is why your Cousin May Fell through the parlor floor today. =09=09-- Ogden Nash http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137