Call for feedback on a Ports-collection change

[Eivind Eklund]

Note: I do not read ports@, so any

On Thu, Jan 08, 2004 at 07:49:25PM -0500, Garance A Drosihn wrote:
> What I want to do is create one new file per port, and then
> move almost all the other files into that new file.  Ideally
> each port would end up with just two files.  The Makefile,
> and this new file (some ports might also need a Makefile.inc
> file).  Especially as disks get ever-larger, I think we're
> better off with fewer-but-larger files, instead of a larger
> number of tiny files.

I think this would be a step backward, at least for the way I work with
ports.

* It makes it harder to separate out information for generic processing 
  Example: Today, I can find that there is a bunch of ports with the 
  same pkg-descr by doing 
  # find /usr/ports -name pkg-descr | xargs md5 > md5list
  # egrep $(echo $(awk '{print $1}' < md5list | sort | uniq -d) | sed s/\ /\|/g) md5list

  That's something that I can just type out, by knowing the standard
  Unix utilities.   I would be (pleasantly :-) surprised if this was as
  easy after collecting to one file (and remember, learning new syntax
  etc makes it harder.)

  [The above is not tested, BTW - I redo these each time I think I 
  should get around to fixing the people that duplicate pkg-descrs when
  they get a repo-copy, and then I always find the amount of work
  involved in contacting that many people too daunting, and go off do
  something else instead.]

* It makes normal development harder; e.g, creating patchsets, and
  testing variations in patches.
  
* It makes it harder for users to understand what is going on (there is
  an extra level of indirection, more or less)
  
* It adds another complication for the day when we will be able to get
  rid of make from ports (this is a personal interest - I believe that
  there are other script languages than make that probably are more
  appropriate to use.)
  

The inode goal is laudable, but I think we should focus on ease of
development (and thus features) in preference to saving disk space.
Disks are getting cheaper all the time, while developer time is always
scarce.  (Of course, any solution that also improve developer
productivity seems nice :-)

Eivind.