From owner-freebsd-ports@FreeBSD.ORG Sun Nov 11 04:37:52 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 0064616A417 for ; Sun, 11 Nov 2007 04:37:52 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: from mail2.sea5.speakeasy.net (mail2.sea5.speakeasy.net [69.17.117.4]) by mx1.freebsd.org (Postfix) with ESMTP id CD2EE13C4B2 for ; Sun, 11 Nov 2007 04:37:51 +0000 (UTC) (envelope-from chuckr@chuckr.org) Received: (qmail 18676 invoked from network); 11 Nov 2007 03:37:39 -0000 Received: from april.chuckr.org (chuckr@[66.92.151.30]) (envelope-sender ) by mail2.sea5.speakeasy.net (qmail-ldap-1.03) with AES256-SHA encrypted SMTP for ; 11 Nov 2007 03:37:39 -0000 Message-ID: <473678CD.8030304@chuckr.org> Date: Sat, 10 Nov 2007 22:36:45 -0500 From: Chuck Robey User-Agent: Thunderbird 2.0.0.6 (X11/20071107) MIME-Version: 1.0 To: freebsd-ports@freebsd.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: 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 04:37:52 -0000 May as well get all my bright ideas out and over with, all at once. You see, I've spent the last few years exploring other OSes, and finally decided I was right, way bakc when I was running FreeBSD to begin with. BUT I have to admit that I saw several good ideas while I was out and about. I have never seen a better package system (at least, in my own opinion, you understand) than FreeBSD ports, BUT the methodology for qualifying dependencies isn't as good as some I've seen, so I wanted to open a discussion about this. If, at the end of this, no one agrees, all I ever ask is that folks give a listen, NOT that anyone actually agrees, so I will happily fold up my tent and slink away. 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. 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? 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. Let me repeat this to get it clearly: the words are used to qualify the dependcency lists, but if a particular port is chosen, then it gets built, period. If a user asks for that sound program explicitly, then it gets built, SOUND word or no SOUND word. It's the dependency lists that have to check and modify themselves. 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. 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. 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.