[SUGGEST] Reform eclipse and eclipse related ports

[Roman Neuhauser]

# linimon at lonesome.com / 2005-10-18 11:29:07 -0500:
> 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.
 
    Would optional use of double metaphone or another algorithm help?
    Also, another variable, e. g. KEYWORDS, could be used.

> > > 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";

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

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

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

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

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

    make search is not The Final Solution, of course, but it can be made
    better. Feel free to mail me any suggestions you have.

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

    Note: The shell is also a User Interface, but I understand you mean
    a Graphical User Interface, or more precisely (because libdialog(3)
    is a GUI toolkit), GTK, QT, and the likes.

    I agree with what you say.

    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.

    In compliance with your assessment that FreeBSD is put together by
    different people scratching their different needs, I'm doing myself
    a favor by contributing the tools that I want to see in the
    operating system. (I'm probably one of three people who use [the
    extended capabilities of] make search, which IMO proves both your
    and mine points.) Unless, or until, someone tries to discourage
    improvements to the interface they dislike, everybody can be happy.

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

    That's in agreement with what the angry guy pushes: don't let the
    rules of yesterday limit the ways you use it today. I don't mind
    you spending time writing a web interface (which I won't use),
    please don't mind me extending the ways make or ls can be used.

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

    The last two paragraphs seem to back the need to extend the basic
    concepts. If we stop thinking in terms of "real" vs "virtual"
    categories, and represent membership in multiple categories in terms
    of symlinks, we can greatly improve the usability by merely doubling
    the number of categories. If we can have

     cnt path
      11 /usr/ports/hebrew
      13 /usr/ports/accessibility
      13 /usr/ports/arabic
      13 /usr/ports/ukrainian
      14 /usr/ports/hungarian
      16 /usr/ports/portuguese
      19 /usr/ports/mbone
      19 /usr/ports/x11-servers
      21 /usr/ports/polish
      21 /usr/ports/vietnamese
      25 /usr/ports/french

    then there's surely room for

      24 /usr/ports/eclipse

    And, 1620 /usr/ports/devel could use a close look at.

-- 
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man.  You don't KNOW.
Cause you weren't THERE.             http://bash.org/?255991