Second "RFC" on pkg-data idea for ports

[Garance A Drosihn]

At 4:00 PM -0400 4/13/04, Charles Swiger wrote:
>Hi, Garance--

Greetings and salutations...

>On Apr 12, 2004, at 11:40 PM, Garance A Drosihn wrote:
>>
>>What I'd like is some idea of whether this project is worth
>>pursuing.  If not, then Darren and I will concentrate on some
>>other, less disruptive project.  If people like the general idea
>>of this project, then we'll see how much of we can do.
>
>You have some interesting ideas, but there seems to be a
>disconnect between the stated goal for this change and
>what you are actually proposing to do.

It is true that I have something of a split-personality when
I talk about this.  I have this somewhat vague set of long-term
ideas, and then the initial short-term project which all that
I'm trying to do right now.

>It seems to me that a project which moved the distinfo or
>pkg-descr files into the port Makefile-- similar to how
>pkg-comment/$COMMENT was done-- would result in roughly the
>same savings of inodes and disk space that your proposal is
>expected to accomplish, would be easier to do, and would be
>less intrusive than trying to replace the Makefile with your
>proposed XML-ish pkg-data format.

Much earlier I had an idea to do something like this, but I felt
it was actually harder to do, due to all the special processing
that would be needed to properly escape values which will span
multiple lines.  It ended up looking messier and messier, instead
of looking like a step forward.  The more I tried to do it, the
more I hated the result.

>I remember some of the pain of dealing with the pkg-comment
>transition: a proposed change that can be done incrementally,
>or not at all for certain ports (ie, if a port has lots of
>distfiles, keeping distinfo external is probably easier to
>maintain) is much easier to accept than an all-or-nothing
>change that breaks backwards-compatibility.

It is probably not clear from my web pages, but I would expect
to phase this in.  My assumption is that it is impossible to
convert the entire ports tree all at once.  (Well, we already
have a script that can do that conversion, but no one would
want to *commit* such a massive change in a single commit!).

The key component for all this is the PdHandlingProgram (*).
That program will be able to work on either a pkg-data port,
or any port in it's current format.  So, the way I would see
this getting phased in is:

    1) write program
    2) write changes to the Mk/* files to use the
       program.
    3) when those seem to be working, commit those changes.
    4) Over time, convert each port to the new format.  We
       could do this in blocks, or only convert any given
       port when that port is being changed for some other
       reason.  Many of the "future extensions" are pointless
       until a significant number of ports have been converted,
       but other than that there should be no reason to rush
       with converting things.

(* = I should think up a better name for that program)

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