Call for feedback on a Ports-collection change

[Garance A Drosihn]

At 10:17 PM -0600 1/8/04, Mark Linimon wrote:
>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).

It could very well be that some of the files should *NOT*
be collapsed into this new file, for reasons like you
describe above.  That's certainly the kind of insight
that I do not have a good-enough feel for.

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

Inside the proposed pkg-data file, the patches can have
whatever names you want.  (That was already part of my
plan). For instance, you could name each patch for the
exact filename it modifies (if you wanted to) -- including
directory names and using '/'s as separators.  It's just
that when the program spits them out, it'll do it into
boring-named files.  That was my thought, at least, I'm
certainly willing to spit them out with other names.

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

That's a lot of DISK SPACE, but no matter how large the
disk is, it is unwieldy to have files which are 100 bytes
per inode, instead of (maybe) 2000 bytes per inode.

When I'm talking about larger disks, I'm thinking that as
the size of the disk increases, the more you're going to
have larger values for f_bsize or f_frsize (in statfvs).
You don't want a 200gig disk with a 256 byte block-size.
And if you have a 8192-byte block size, then you're wasting
disk space on almost every file in the ports-tree.

Not only that, but you're killing performance when doing
operations on the entire ports tree (an operation such as
'cvsup').  The amount of time to find-and-read ten small
files is going to be much more than to find-and-read one
larger file (particularly if that entire larger file can
still fit in a single block on the disk).

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

Let me just say that I have some long-term ideas which are
a bit more ambitious, but this idea is a doable first-step
towards those ideas.  I don't really think *I* can do the
longer-term ideas, but I can leave the ports-tree in a
more flexible state for other projects to take advantage of.

-- 
Garance Alistair Drosehn            =   gad at gilead.netel.rpi.edu
Senior Systems Programmer           or  gad at freebsd.org
Rensselaer Polytechnic Institute    or  drosih at rpi.edu