Call for feedback on a Ports-collection change

[Edwin Groothuis]

On Thu, Jan 08, 2004 at 07:49:25PM -0500, Garance A Drosihn wrote:
> The method is also pretty modest.  The only thing that makes
> this a big project is the need to do it across the entire
> ports collection, and without causing any disruption.

That's always a good goal :-)

> What I want to do is create one new file per port, and then
> move almost all the other files into that new file.  Ideally
> each port would end up with just two files.  The Makefile,
> and this new file (some ports might also need a Makefile.inc
> file).  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.

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.

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 bij a bunch of seperate
tools (no official standard too)).

> I would also write a single simple program, which knows how
> to find the correct info for any given purpose.  Thus, the
> format of the file should not be important.  The program
> would know what to do for both "old-style" and "new-style"
> ports, so we don't have to convert the entire collection
> at once.

if [ type = oldstyle ]; then run make; else do-your-magic; fi

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

Then we have the bootstrap problem. You will have to make a port
which installs your make(U). That's okay, it's a one time thing.
The next step will be more difficult, the re-distribution of changes.
At this moment the executable data is in bsd.*.mk, which means that
when you cvsup, you have the latest (and compatible) ports and
executable data. For ports following your make(U), how do you know
if your make(U) has to be recompiled because of new configurable
or executable data?

> Does this seem like a reasonable project for me to pursue?
> Does it conflict with other projects which are already in
> the works to do a similar restructuring?  I wouldn't want
> to start this project if no one thinks it is worth doing.

Only one way to find out...

Despite of your fear for bsd.*.mk, the whole system actually makes
sense: The glue (in this case: make(1)) is fixed, the globally
executable and configurable data which is hard to understand
(sometimes) is controlled by a small group of people who do QA on
it, while the executable and configurable data in the ports itself
are very dumb, most of the time only some configurable data.

But yeah, making one thing smarter (for example, the MAN, USE_GNOME,
PORTDOCS and INFOFILES variables) make the ports files smaller and
smaller...

This has ended up about 80 lines longer than I hoped it would be :-)

Edwin

-- 
Edwin Groothuis      |            Personal website: http://www.mavetju.org
edwin at mavetju.org    |          Weblog: http://weblog.barnet.com.au/edwin/