Call for feedback on a Ports-collection change

[Mark Linimon]

> and then fill that directory with files patch.001 through
> patch.042.

I think this is a step backwards.

Let's consider the problem from a maintainence standpoint.

The files that change the most rapidly are files/patch-*,
because they are affected both by port updates, and also
changes to the underlying infrastructure such as the
recent gcc3.3 import which we are still struggling with.
Giving these things symbolic names helps to keep clear
what's doing what.

Next most rapid to change are Makefile and distinfo and
that's just talking about version tracking.  Some external
code is released on a quite regular basis.  Sometimes this
can be dealt with by just a change to portrevision and
checksum; sometimes not, and something else needs to change
such as portepoch or the install tweaks.

The next most rapid to change are plist and those tend to
change less often than the distinfo changes, but there
are the occasional exceptions (generally chasing down
plist bugs found during packaging).

The next most rapid is the pkg-descr and that's generally
because the URL move around (of course, that affects
Makefiles too).

The pkg-message and pkg-comment files were the ones that
were mostly static.  The reason pkg-comment was nuked was
that it was only one line.  Remember, too, that during
the conversion, the ports tree was unstable for a time
(having a free-form text line with all kinds of special
characters really gave the make infrastructure a bad case
of gas), and in addition there was a lot of repo-churn.
I'm still not personally convinced it was worth the pain, 
but that's water under the bridge.

I think the same arguments pro and con could be made
for incorporating pkg-message.  There would be N less
files, but N more opportunities to mess up the Makefiles
(if that was the way you were going to go about it).
And then, there's the repo-churn.  Every single consumer
of cvsup would wind up having to reload a copy of every
single port.  That's a lot of bandwidth, too.

But in your plan, if I understand it, a change in any
of these things results in a change to a single, unified,
file.  Now I can't go to the CVS logs and quickly say,
oh, the last year's worth of Makefile changes were just
to keep up with infrastructure changes; the distfile hasn't
changed in 2 years.  (This is a very common situation).
Now, for each change, you have to go through and find out
exactly what it applied to.

Now let's consider maintainability once again.  The ability
to separate the patches into discrete files with descriptive
names is a very powerful thing if you're someone like me
who winds up trying to do updates to a large number of
ports.  I find the ports with a large number of patches
stuck together in patch-aa, patch-ab, etc., to be
incredibly frustrating to work with.  You can't even
tell from glancing at them if they even overlap.  I think
it would be a mistake to take away the ability to rapidly
browse these files.

In any case worrying about inode count strikes me as an
early- to mid-90s kind of problem.  Fry's has 250Gs on the
shelf.  ISTM that there's room for lots of inodes on that.

Honestly, I think if some work was done that would touch
every port in the ports system, it ought to be something
that gave us so much generalization as a tradeoff for the
pain that would ensue (something like some kind of meta-
descriptor language?) that it would be worth it.  I really
can't agree that this is it.

To me, I really think you're trying to solve a problem
here that just isn't a problem for the majority of users,
at least with respect to the amount of repo-churn and
bandwidth-churn it would entail.

mcl