Re: RFC on HOMEPAGE inclusion in INDEX

[David Snyder <dasnyderx@yahoo.com>]

Andrew Dalgleish wrote:
> On Mon, Jan 26, 2004 at 09:53:54PM +0100, Marc Espie wrote:
> 
>>> I don't have a firm opinion, one way or the other.
>>> Having HOMEPAGE around is useful.
>>> having another field in INDEX makes it even longer.
> 
> 
> Can you generate the output dynamically using something like this?
> make search key=foo show=HOMEPAGE
Andrew,

It would be possible, just hadn't thought about doing it that way.  If 
the inclusion of the HOMEPAGE is approved and the method of 
implementation is as you suggest, I'll be glad to code it up.

However, the above implementation would, IMO, defeat the purpose of 
including the HOMEPAGE in the 'make search {key,name}=foo' output.  One 
of the reasons that I put the HOMEPAGE into the 'make search' output was 
the fact that, if I saw something of interest, I could merely put the 
HOMEPAGE listed in the search result set into my preferred browser and 
take a closer look at the listed item.  With the addition of the 
qualifier 'show=HOMEPAGE', the ease of getting additional info on (and 
possibly serendipitous discovery of) a port would be defeated.  A user 
would have to either, 1) run 'make search' _twice_ in order to get the 
HOMEPAGE(s) for a given search result or, 2) be knowledgeable enough of 
port variables so that the 'show=' portion of the above call could 
include the additional information requested.  The former defeats the 
idea for the inclusion of the HOMEPAGE in the 'make search' output, and 
the latter would turn the ports/Makefile into a nightmare for the 
'search:' condition because it would have to prepare for any and/or 
every possible variable's inclusion in the 'show=' qualifier.  The 
appending of the 'show=' qualifier would lead to the extraordinary 
bloatage of the ports/INDEX (way beyond the ~67K size increase with the 
inclusion of the HOMEPAGE variable) due to the possible inclusion of 
each possible port variable's value in the ports/INDEX file for quick 
retrieval.  On the other hand, if the port's variable value was 
retrieved at the execution of a 'make search', it would slow the 'make 
search' down _considerably_.

Therefore, I would advocate for, as I submitted before, the inclusion of 
the HOMEPAGE variable in the ports/INDEX file, and the output of the 
variable's value in the result set of a 'make search' call.  This gives 
the user a pointer to a (possibly) fuller description of a port and 
increases the size of the ports/INDEX by (as the port tree exists now) 
only ~67K.

David