From owner-freebsd-ports@FreeBSD.ORG Tue Oct 18 16:29:13 2005 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 87CCD16A420 for ; Tue, 18 Oct 2005 16:29:13 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66]) by mx1.FreeBSD.org (Postfix) with ESMTP id C22A743D49 for ; Tue, 18 Oct 2005 16:29:08 +0000 (GMT) (envelope-from linimon@lonesome.com) Received: by mail.soaustin.net (Postfix, from userid 502) id 6B9B03000; Tue, 18 Oct 2005 11:29:07 -0500 (CDT) Date: Tue, 18 Oct 2005 11:29:07 -0500 To: Mark Linimon , freebsd-ports@freebsd.org Message-ID: <20051018162907.GB14192@soaustin.net> References: <43522953.6050700@ebs.gr> <1B8112AF-8C0E-4BA0-8D1C-DA6AD529F327@softweyr.com> <20051017153024.GA23494@arabica.esil.univ-mrs.fr> <20051017212748.GD71766@isis.sigpipe.cz> <790a9fff0510171505i4010cc05yc30f67d459d1a0e4@mail.gmail.com> <20051018010446.GH71766@isis.sigpipe.cz> <20051018011616.GA57969@xor.obsecurity.org> <20051018153752.GB11790@soaustin.net> <20051018160725.GB87664@isis.sigpipe.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20051018160725.GB87664@isis.sigpipe.cz> User-Agent: Mutt/1.5.9i From: linimon@lonesome.com (Mark Linimon) Cc: Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports 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: Tue, 18 Oct 2005 16:29:13 -0000 On Tue, Oct 18, 2005 at 06:07:25PM +0200, Roman Neuhauser wrote: > > That highlights my point that IMHO we need two different functionalities: > > 'search' and 'browse'. 'make search' is barely adequate for searching. > > What are you missing from make search? I'll try and add it if it's > within reasonable bounds of complexity. e.g. searching when you don't know the exact spelling of the name. It's the "dictionary problem" -- how do you find the meaning of a word when you're not sure what the word is? > > We have nothing at all for browsing (unless you count reading an entire > > list of ports in hierarchy as 'browsing', which even an old command-line > > kind of guy like me thinks is crude). > > Can you define 'browsing'? "show me the ports that have something to do with the Internet"; "show me a list of plugins that work with Apache2". > How will the Wes' colleagues find it? You need to be able to find > a port to install it. If a port is required to make sense of the > structure, we need a bootstrap mechanism, like something in the > base. Like, ls. Don't be silly. Neither portupgrade nor cvsup are in base. People pkg_install them and then they're good to go. ls is _not_, by any stretch of the imagination, an adequate tool unless you already have a pretty good idea of what it is you're looking for. I really do not believe that anything with a UI belongs in base, and I believe that 'search' and 'browse', to be useful to the largest number of people, need to be UI-based; whether that's as applications, or from web pages, or more likely, both. > I would certainly prefer if we considered the fs structure to be the > primary interface (and treated it accordingly). I'm weird, I know. It's always going to be the 'primary' interface but if we don't build tools on top of it, it's simply going to limit the ports tree's usefulness to people who aren't as hardcore as you or I are. fwiw, I rely extensively on a little script that I wrote that greps things out of the contents of Makefiles. I am familiar with these kinds of tools. But, I mean, honestly, I think I can state without much fear of contradiction that I have as good a working knowledge of what's in the ports tree as anyone. Even so, the other day I went looking to see if there was any port specifically geared to synchronizing file systems on two peer machines (rather than, e.g., geared to just backing up a file system). It was really painful to do that, and it shouldn't have been. None of the existing tools are even vaguely adequate for that. mcl