Call for feedback on a Ports-collection change

William DeVries william_devries2000 at
Thu Jan 8 22:46:41 PST 2004

--- Garance A Drosihn <drosih at> wrote:
> 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.

The pkg* files in this directory, and the packing
list(p-list) are copied in the package manager's
database directory for the port, so the way it's set
up now is logical, except for the remove of
pkg_comment file.  This some of these file are
modified in some rules, like the p-list, so in your

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

What do you mean by "spit them out." If you mean
extract the files then the changes needed to do this
would probably be fairly trivial(I haven't read the
whole file).  
   As I understand this stuff, you could use tar to
bundle up the files, then add an a new rule to to extract the files.  Then in the default
rule, the one that gets called when you type 'make,'
you could call your special rule.  To maintain
compatibility with current ports, this new rule should
not crash and burn if one of your new files is not
present, thus allowing the use of the old system.  I
not going to pretend to know if this is suggestion is
actually correct.  

If you plan on storing them in variables in make, then
it would be much more complicated.  For the pkg* and
p-list files the changes to would be
fairly easy, but the patches would be somewhat

It sounds like(from other post) you mean the first.

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

I would imagine that most people don't care about a
few megabytes of disk space.  A clean understandable
design is probably more important, not that we have
that now.

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

The time that the port system spends reading and
writing to these files is probably very small, and
thus not important.
    "Premature optimization is the root of all evil"
        - D. Knuth
I don't understand how 

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

I don't think what you are suggesting is needed, but
there are many things that could probably be done here
that would be very useful, like documenting of all the
rules in  What are the other ideas, just
because one idea is not liked, does not mean the other
will be.

If I got something wrong, forgive me.

--William DeVries

> -- 
> Garance Alistair Drosehn            =  
> gad at
> Senior Systems Programmer           or 
> gad at
> Rensselaer Polytechnic Institute    or 
> drosih at
> _______________________________________________
> freebsd-ports at mailing list
> To unsubscribe, send any mail to
"freebsd-ports-unsubscribe at"

Do you Yahoo!?
Yahoo! Hotjobs: Enter the "Signing Bonus" Sweepstakes

More information about the freebsd-ports mailing list