[SUGGEST] Reform eclipse and eclipse related ports

[Mario Hoerich]

# Mark Linimon:
> On Wed, Oct 19, 2005 at 11:40:18PM +0200, Roman Neuhauser wrote:

[ Locating ports when you don't know the spelling ]
> >     Also, another variable, e. g. KEYWORDS, could be used.

Personally, I doubt this'd do much good.  With generic keywords
(like "mp3" or "video") a search yields too many hits rather fast,
whereas people are quite likely to outright miss more specific terms.

Besides, every port maintainer probably has his/her very own idea 
how to properly set KEYWORDS, so that i.e. "mp3 player" hits
amaroK and juk, but misses xmms.  Synchronizing this sure seems
like a can of worms to me.


[ "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.)

A man-page.  Or at least a proper help.

| $ make search
| The search target requires a keyword parameter or name parameter,
| e.g.: "make search key=somekeyword"
| or    "make search name=somekeyword"

doesn't exactly tell me about cat= or the difference between
key= and name=.

Other than that: a less non-standard syntax.  I'd highly favor
portsearch [-c<cat>] (-k<key> | <name>). 


> Well, there _are_ a few Internet-related ports in net-mgmt, wwww, ...

This applies to quite a lot of ports, I think.  See xmms, for example.
It took me quite a while to realize the 54 xmms-$foo ports in audio
didn't include xmms itself.  I finally located it via LIB_DEPENDS.


> >     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.

I'd favor a set of tools, a library and an ncurses frontend *in base*.
The current set

  * portmanager
  * port{up,down}grade
  * portversion
  * portsnap
  * portsman
  * pkg_{delete,remove}
  * pkg_{add,install}
  * pkg_info
  * pkg_{cut,rm}leaves
  * cvsup (what happened to csup btw?)  
  * make search
  * make [fetch]index
  
isn't exactly consistent in either naming or behavior and there's
probably quite a couple of reinvented wheels inside.  The ports
collection being one of the most visible features of FreeBSD, I
think this is bad.

Oh, I'd like my bikeshed blue with dark green stripes, btw.


> 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. 

The thought is actually quite nice, but the logical groups aren't 
disjoint on any count.  The "ports for end-users" contain plenty
of ports for devs (e.g. audio/p5-Filesys-Virtual-DAAP), whereas
many actual end-user ports (e.g. Firefox) are elsewhere.

So essentially, it doesn't really help (me). 

If you're serious about improving the browseability, then the only
real way _I_ can see is to separate applications from libraries and
$lang-ports.  Fwiw, I'm aware this implies literally thousands of
repocopys, and that I'm most likely not the one doing them or 
dealing with the fallout.  It might still be worth consideration
as a long term plan, though.

Regards,
Mario