[SUGGEST] Reform eclipse and eclipse related ports

[Mark Linimon]

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