From owner-freebsd-ports@FreeBSD.ORG Sun Nov 11 08:13:32 2007 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5BCB816A550 for ; Sun, 11 Nov 2007 08:13:32 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by mx1.freebsd.org (Postfix) with SMTP id B27FC13C4A5 for ; Sun, 11 Nov 2007 08:13:31 +0000 (UTC) (envelope-from LoN_Kamikaze@gmx.de) Received: (qmail invoked by alias); 11 Nov 2007 08:13:25 -0000 Received: from nat-wh-1.rz.uni-karlsruhe.de (EHLO mobileKamikaze.norad) [129.13.72.169] by mail.gmx.net (mp044) with SMTP; 11 Nov 2007 09:13:25 +0100 X-Authenticated: #5465401 X-Provags-ID: V01U2FsdGVkX1+blrUXiJWbVlXIoPVKhrKu77TbBGHhTQ9NFTyHL5 /sGW32LLnj45Hq Message-ID: <4736B9A0.7040409@gmx.de> Date: Sun, 11 Nov 2007 09:13:20 +0100 From: "[LoN]Kamikaze" User-Agent: Thunderbird 2.0.0.6 (X11/20071101) MIME-Version: 1.0 To: Chuck Robey References: <473678CD.8030304@chuckr.org> In-Reply-To: <473678CD.8030304@chuckr.org> X-Enigmail-Version: 0.95.5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 Cc: freebsd-ports@freebsd.org Subject: Re: suggestions for ports screening 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: Sun, 11 Nov 2007 08:13:32 -0000 Chuck Robey wrote: > ... This might either turn into a bikeshed or a creative brainstorming. I hope for the latter, so I take part. > Anyhow, here's the suggestion. The system we have, currently, is > basically dependent on people who write ports instrumenting options to > include or not include various options. A very large portion of those > options are written up in such a way as to make it nearly impossible for > a non-expert to figure out if a particular option is good for their use > of not. My rule of thumb is to stick to the defaults if I don't know what I'm doing. I think that could be put mentioned in the handbook, just to make beginners feel more confident about what they're doing. > An example? If a programmer asks you if you want the blotz program (I > make up great fake names, don't I?) hows the user going to know the the > blotz program is a particular sound program, when they have no sound card? That problem really exists, though. > There are ways to fix this, you know. Read on. > > OK, My suggestion is for a two level system (yes, some of you are going > to recognize some of this from other OSes. G'wan, brag about it). The > first part is a small list of keywords (well, not terribly small, maybe > 100-200 of them, but most user's personal lists would be far shorter). > These words are descriptive of the sort of machine environment the user > wants, like, they might have the words SOUND, FMRADIO and TELEVISION to > show that they care to have those sort of dependencies built. All ports > would be required to export a list of words that they check for, before > they build. If a browser sees no SOUND word, it requires to sound > dependencies be built. I like the sound of that. It might be a bigger change that would have to be implemented into ports over a long period of time. And of course it would only appear in ports where maintainer are willing to spend the time to support it. > These dependencies can show up on the list in the form of KEYWORD=VALUE, > where value can be used to point towards a user's preference. A user > might set BROWSER=www/seamonkey,www/mozilla in the list, so this gives a > port all the info it would need to match dependencies nicely, without > having to get interactive about it. How would you deal with cases in which following the users wishes is not supported. What if a user has SOUND=direct defined to tell programs to use /dev/dsp instead of a sound server like arts or estd? Most KDE applications only work with arts, no matter how much you wish otherwise. > OK, this is only the first part ... the second part is a list of the > names of ports. This REJECT list serves as a rejection filter: if a > port finds it's way upon that list, it can't get put on any dependency > list at all. I, personally, never like any Samba ports, so I could > stick all the Samba ports on the REJECT list, or I could just fail to > put SAMBA as a keyword. My choice, although if I stuck a particular set > of ports on that list, I'd have to watch new ports, so new Samba port > didn't sneak past me. Still, it would allow a user to really have all > the control anyone could ask for. or they could ignore it and still not > face disaster as long as they maintained the KEYWORD list. That's kinda possible already. .if ${.CURDIR:M*/ports/*samba*} IGNORE= I don't like samba! .endif This would keep everything with samba in the name from being built. I don't know how the depending ports would react to that, though. > 3 stale to the first programmer who notices where I stole the idea from, > and a used mousetrap to him (or her?) who knows the correct name of the > KEYWORD list. If you hate the idea, just say so, believe me I will be > catching all responses, and I will report your overwhelming acceptance > or rejection, as the case may be. It shouldn't take a master's degree > to guess my own opinion. I came over from an OS without a package system (Windows), so I've got no idea where you took all that from.