[SUGGEST] Reform eclipse and eclipse related ports

[Roman Neuhauser]

# linimon at lonesome.com / 2005-10-20 15:03:15 -0500:
> 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').
 
    That's two things: how the data is stored, and how it is accessed.

> 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.
 
    I agree with you here. make search was a bit tough to debug, and I
    plan to move the code to a separate script that will be run by make
    search.

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

    So, would (virtual) membership in net (or inet) help here?
 
> > > "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.

    But then you'll have to create and use every tag anyone could
    possibly think to search on. Otherwise, the tag system would have
    the same problem as the vcat system.

> Then you get people thinking about the tags as meta-information and
> then whatever underlying directory structure becomes an implementation
> detail.

    FMPOV youre just proposing to use a different transport for the
    information the category directory names and contents carry now. If
    the filesystem were used to represent membership in additional
    categories, the directory structure could carry that
    metainformation, and we would achieve comparable results with
    fewer parts.

    Besides, this is exactly the thing I fear will happen: that someone
    else will claim my interface their implementation detail, and I'll be
    denied my favorite interface.
 
> > > > 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.
 
    You said above that the underlying directory structure could become
    an implementation detail. If you stop thinking of the directory
    layout as a major human interface, it'll cease functioning in that
    regard quite quickly. See /etc/sysconfig on an RHEL system.

    The user friendliness (FMPOV) of /usr/ports lies in the fact that
    it's all easily accessible to humans. Makefiles are quite easy to
    read and use, and all information is stored in human accessible
    representations in text files. This is a huge plus of the ports, and
    should be kept in mind.

> 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.)
 
    Two tricks that I can see:
    
    - *what* are "all the interesting tools"? IOW, emacs or vim for
      developers, kportman or gportman for users?
    - how would the users find the metaports?

> > > 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.
 
    You're mixing two problems here, and completely missed my point.

    The interface: web client is a very fine tool for that because
    you'll use it to manipulate the result set. The idea of installing
    software by clicking on links in a web page isn't that comfortable.

    The search: besides being smarter than 30 lines of awk about the
    data it processes, the data Google has is completely different, much
    richer, and quite self-describing. An average article about
    std::vectors is much longer than any COMMENT, and you won't get much
    better results even with a 3d graphical virtual reality browser.

    And, my point was that Google isn't mostly used to find "the" page,
    I rather want "a" page on std::vectors. If you don't know that the
    port you're looking for is a CORBA ORB, you're probably screwed with
    or without a web interface, but you can already do ls -d */*orb* if
    you do.

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

    If the directory structure becomes, and is treated as an
    implementation detail, it will sooner or later lose its current
    accessibility. I like to ls-and-see around ports.
 
> [mentions language categories]

    That was the top of
    
    for c in /usr/ports/[a-z]*(/); do echo "$(ls $c | wc -l) $c"; done | sort -n

    IOW, I was pointing at the smallest categories, whether they were
    language or other was unimportant.

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

    Can you try again? I don't understand the question.
 
> 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.

    Well, I do think that splitting a heap of 1620 ports into 67 chunks,
    each of manageable size, would help. It would add new, finergrained
    ways of looking those 1620 ports that aren't organized any further.

    Also, the average number of ports in a category is unknown, but even
    if I accept your guesstimate of 569 categories, the number is still
    three times smaller than the 1620 in devel, so it looks like a win.
    Thanks, assured me that it is a worthwile project to set on.
 
> 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.

    I haven't seen that page since a few years. Here's my .2 if you're
    interested:
    
    The dictionary in top page adds information which isn't in the
    ports, and that's the added value that makes finding something
    without knowing the right words possible: it's described in more
    ways. It's not the transport that makes it better, it's the metadata
    it adds. If the information that is in the web page was in
    /usr/ports/README (possibly with reST or wiki format for easy
    conversion to html), it could be used with or without a browser or
    an internet connection.

    The search form is inferior to make search, it provides no way to
    enter specific queries (all you have is All / Package name /
    Description) leading to false positives and negatives in results.

    Doing this well on the web is hard, because static forms have static
    complexity, and eg the complex search form in bugzilla doesn't get
    any smaller whan you don't use all its knobs.  On the command line,
    the complexity of the interface grows with the complexity of your
    query.

    The conversion to html makes viewing pkg-descr files somewhat easier
    (with urls made into links, which is nice), but getting at the
    Makefile and other files in the port directory is somewhat harder.

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

    Ok, bye.

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