Second "RFC" on pkg-data idea for ports

[Garance A Drosihn]

At 11:16 AM -0400 4/13/04, Brian F. Feldman wrote:
>
>... will cost us ease of use in creating and updating ports,
>certainly, because the developer cannot simply type
>`diff file{.orig,file} > patchfile' and be finished with it.

There would be an extra step (or two) here, yes.

>Searching through UNINSTALLED ports, I often want to find out
>what port would have a certain file in its PLIST,

If the port is not-installed, then it does not have to be in
the pkg-data format.  One idea of the pd-handling-program is
that it knows how to handle ports in either their present
format or the new pkg-data format.

>and I also would not be able to just
>`grep ^whatever ports/foo/*/pkg-plist' in the common,
>single-plist case.  Of course, the tool wouldn't make it
>that much harder to do something similar, but it would
>be twice the typing.

We could maybe hide that typing behind a make target, similar
to `make search index=xxx' and `make search key=yyy'

>I'm not sure I understand why you don't just go all the way
>and embed it in the Makefile.

That was actually my original idea, but after working with it
a bit I felt it was just too unwieldy.  I'm also going to claim
(without proof...) that we might eventually be able to move
so much into the pkg-data file that most ports could use the
exact-same Makefile.  But that would be way off in the future,
if ever...

>Is it because make(1) is "slow"?  Since pkg/COMMENT turned
>into pkg-comment and then COMMENT= in the Makefile, it's not
>hard to imagine the same could be done for
>pkg/DESCR -> pkg-descr -> DESCR=, ...

I was here for the pkg-comment -> COMMENT change.  It was not
trivial.  It was committed, it broke things, and it had to be
backed out.  In fact, that was exactly what inspired this idea.
After more effort was put into it, it was committed again.  And
that was for a single-line value, which had no embedded newlines
and which was less-likely to have "special escaping characters"
in it than something like pkg-descr is.

I think that stuffing all these values into MAKE variables is
much more trouble than it is worth.  That is just MO, of course.

>Heck,  even if Makefile became, itself, the XML PkgData file
>that defines  everything in every port, it's not like there
>couldn't be a portmake(1) that did "PkgData --Makefile" and
>called make(1) with all the rest of its  arguments except
>doing a file descriptor redirection or temporary file
>redirection and adding a -f <contrived_Makefile>.

Hrm.  That is an interesting idea which I had not thought of.
Maybe do that as a future project.  For now I assumed that
people would expect me to keep the ability to:

    cd /usr/ports/category/portname
    make && make install && make clean

Ie, that those *exact* commands would continue to work, with
the exact same result.  And I think implies a standard makefile
in that directory.  And a makefile which does not depend on
installing some new version of the `make' command.  Those were
just the assumptions I started with, though.

>Is there some reason you would stop where you did other than
>just to keep the Makefile separate?

Mainly to pick a project which Darren and I might actually
complete.  This is mainly moving forward because a recent RPI
graduate (Darren Lim) has a few months where he has some spare
time.  If we can *complete* this project in that time, all the
better for everyone.  If it takes longer than that, then Darren
is gone and I am my usual lame always-out-of-time self.  The
project will never get done.

Also, while Darren now has a Phd, he has done practically zero
work with sysadmin or systems-programming.  So, we are not open
for "wish-lists" of things that people would rather we work on.
There are many very good projects waiting to be done, but that
doesn't mean Darren is the right guy to tackle them.

>This is a very slippery slope.  I don't think ports should be
>an XML package definition -- that's just not the BSD way.

Well, I am guessing this might be taken as a "NO" vote...  :-)

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