Call for feedback on a Ports-collection change

[Garance A Drosihn]

At 12:26 PM +1100 1/9/04, Edwin Groothuis wrote:
>Garance writes:
>  > 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
was done.

>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)
    distinfo
    Makefile
    Makefile.inc
    pkg-comment    (well, I guess that's gone now)
    pkg-deinstall
    pkg-descr
    pkg-install
    pkg-message
    pkg-plist
    pkg-req

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

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

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