Date: Fri, 21 Oct 2005 14:54:41 -0700 From: "Michael C. Shultz" <ringworm01@gmail.com> To: freebsd-ports@freebsd.org Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports Message-ID: <200510211454.41789.ringworm01@gmail.com> In-Reply-To: <20051018162907.GB14192@soaustin.net> References: <43522953.6050700@ebs.gr> <20051018160725.GB87664@isis.sigpipe.cz> <20051018162907.GB14192@soaustin.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 18 October 2005 09:29, Mark Linimon wrote: > 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 My .02 cents worth - - - Would the ports system handle adding another level to its directory structure? A quick way to organize some of the 1000+ port categories? -Mike
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200510211454.41789.ringworm01>