Call for feedback on a Ports-collection change
Garance A Drosihn
drosih at rpi.edu
Thu Jan 8 17:57:11 PST 2004
At 12:26 PM +1100 1/9/04, Edwin Groothuis wrote:
> > 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.
>Don't get me wrong on this, I'm not saying that you
>shouldn't do this. All I want is to give my experience
>with the current system.
Sounds like a good thing for me to hear... :-)
>The Makefile contains two kinds of text: configurable data and
>executable data. The configurable data is the portname, version,
>maintainer etc. Pretty much static, and manually entered. The
>executable data is mostly the post-extract (REINPLACE_CMD), the
>do-install (INSTALL_DATA) and post-install stuff (CAT). This one
>too, static and manually entered.
I'm immediately confused. I am not proposing changes to any of
the port's Makefiles, except maybe that I'd pull PKG_COMMENT out
of the make files and into the new file. In fact, I started to
look into this project as an alternative to the PKG_COMMENT
changes, but I didn't get far enough along before that change
>pkg-descr is only static data, doesn't change too often
>(if at all).
>The other two files (distinfo and pkg-plist) are machine
>generated (distinfo by "make makesum", pkg-plist often just
>a bunch of seperate tools (no official standard too)).
My list of "common files" has:
files (a directory, and as such can be multiple files)
scripts (a directory)
src (? - a directory, but I forgot why I check for it)
pkg-comment (well, I guess that's gone now)
Remember that all i want to do is decrease inodes. If I can
collapse even half of those into a new file, it'll be a step
The fact that distinfo and pkg-plist are machine-generated
does not mean that they can not be collapsed into this new
file. It just means that if they *are* collapsed into it,
then the program which generates the info has to know about
the new file.
> > I think the easiest and clearest way to implement
>> this would be one C program, and not 800 lines of /bin/sh
>> commands and deep make-magic.
>There you make a wrong assumption about the bsd.*.mk and make(1).
>bsd.*.mk is doing the same as the local Makefile, it sets global
>configurable data and has executable data in it.
>Make(1) is doing the magic of glueing the the configurable data and
>the executable data. That is what you're going to make again. Except
>that the executable data is moved from bsd.*.mk to your make(U).
I'm not sure why you mention 'make'. The program I'm talking
about is going to be a trivial little thing which will do nothing
more than read info from the new file, and (most likely) write it
out to separate files under the 'work' directory, when building
a port. Nothing to do with dependencies, last-chg times, make
What I was refering to was all the pain that people went through
when trying to move PKG-COMMENT into a make variable, to get rid
of that one file. There are quoting issues when you try to do
that via sed commands and make-magic that I just don't want to
get into -- particularly when handling things like patch files!
>This has ended up about 80 lines longer than I hoped it
>would be :-)
I think one of the biggest challenges of this project will be
trying to read everyone's thoughts on it... :-)
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
More information about the freebsd-ports