Date: Thu, 20 Oct 2005 15:03:15 -0500 From: linimon@lonesome.com (Mark Linimon) To: freebsd-ports@freebsd.org Subject: Re: [SUGGEST] Reform eclipse and eclipse related ports Message-ID: <20051020200315.GA25164@soaustin.net> In-Reply-To: <20051019214018.GA5180@isis.sigpipe.cz> References: <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> <FC88505D-7FB0-4AF3-821B-BBB88B0E82C7@softweyr.com> <20051018153752.GB11790@soaustin.net> <20051018160725.GB87664@isis.sigpipe.cz> <20051018162907.GB14192@soaustin.net> <20051019214018.GA5180@isis.sigpipe.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Oct 19, 2005 at 11:40:18PM +0200, Roman Neuhauser wrote: > > > 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. > > Would optional use of double metaphone or another algorithm help? > Also, another variable, e. g. KEYWORDS, could be used. Please feel free. I just feel uneasy about having things like that encoded in Makefiles. I would rather see separate tools which 'make search' could then invoke -- but then, so could any kind of web-based app. (The old Unix philosophy of 'small tools in combination'). IMHO we have too much monolithic sh/sed/awk/perl magic in the make-framework as it is but that's an axe I will grind in a different venue. > > "show me the ports that have something to do with the Internet"; > > What are you missing from make search cat=net ? (I'm not suggesting > you don't have valid complaints, I'd like to learn about them.) Well, there _are_ a few Internet-related ports in net-mgmt, wwww, ... > > "show me a list of plugins that work with Apache2". > > Create a virtual category, apache_mod, and then: > > make search cat=apache_mod > > Go a step further, use materialized virtual categories, and do > > ls apache_mod > > If you think this wouldn't fly, I'd also like to hear the reasoning. Because now you have to create a virtual category for anything that anyone could possibly think to search on. Creating some kind of tag-based system would be better. Then you get people thinking about the tags as meta-information and then whatever underlying directory structure becomes an implementation detail. > > > 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. > > I don't think I am. I'm pointing out a chicken-and-egg condition > present in your proposal. I don't think there is any such thing. People install portugprade and cvsup without searching for them. They, and other, tools are well-known. Many more ports (in fact the majority) are not. So if you create some kind of port-browser tool like portmanager, people can still install that. The documenation about the port system can (and should) document the management tools, outside of the need to run 'make search' to look for them. Or perhaps someone(TM) could come up with meta-port that would pull in all the interesting ports management tools -- one meta- port for users, one meta-port for developers. How would that sound? (Note: this is a trick question.) > > Neither portupgrade nor cvsup are in base. People pkg_install them > > and then they're good to go. > > Neither tries to facilitate the browsing or searching of the > collection, and I consider their being part of the problem they try > to solve their weakest spot. You're entitled to your opinion. > > 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. > > Same applies to Google, or basically any search interface, or, > closer to the topic, to FreshPorts, which I used about thrice in my > life, BTW. Well, if you don't think Google is an easier interface to use for vague queries than 'make search' or 'ls', by all means, stick to it. My own opinion is that you're going to be in a minority but I'm not going to spend any more time convincing you otherwise. > I've learned over the last 15 years that the most comfortable UI for > the majority of people is a single OK button in the middle of the > screen. I'm fine with that unless someone tries to shove it down > *my* throat. I never said we'd get rid of 'make search'. What I said is that I believe is that for a large group of people it is not going to meet their needs. I don't know where you came up with the idea that I was discouraging its use. I just don't think it adequately solves the problem. Your Mileage Apparently Varies. [mentions language categories] > then there's surely room for > > 24 /usr/ports/eclipse > > And, 1620 /usr/ports/devel could use a close look at. The problem is: how do you present the information about categories? If we let every logical group of 24 ports have its own category*, and eliding for sake of this discussion whether it is physical or virtual, now you have up to 13666/24=569 categories. Presenting a list of more than a couple hundred of _anything_ is just useless, as you can see by trying to look through the devel/ports (no matter whatever mechanism you choose). If you break devel/ into 1620/24=67 categories you haven't solved any real problem; you've instead moved the problem up one level and spent a great deal of developer time to do it. Now, instead of all this email debate, a few days ago I talked Edwin Groothius into implementing a test idea about how to break up the existing category list on http://www.FreeBSD.org/ports/ into logical groups. It's inadequate but a) it's better than the flat space and b) it's actual code rather than just talk. I will note that there has been _zero_ feedback on this change, pro or con. IMHO it's a little, tiny, step towards exploring ideas about how to display this information. And frankly at this point I'd rather try to continue to prototype different approaches than spend any more time on this discussion. mcl * which many people want to do, from reasons ranging from valid to IMHO mere ego-boosting
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20051020200315.GA25164>