Second "RFC" on pkg-data idea for ports

Brian F. Feldman green at
Tue Apr 13 08:16:24 PDT 2004

There are distinct advantages to separating content in different files: the 
Unix way is for each tool to do a job and do it well, and this PkgData tool 
would be doing many jobs that would otherwise be done well by single tools 
operating on each type of data (pkg-plist, distinfo, patch, ...).  This does 
not mean that I believe the proposal to be a bad idea: I think it is a good 
idea as a separate "source package" tree generated from the "ports" tree.

The ports tree just really isn't all that big for modern disks, and 
certainly it does not seem to be growing faster than disks either.  Saving 
this disk space 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.  Searching through UNINSTALLED ports, I 
often want to find out what port would have a certain file in its PLIST,
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.

I'm not sure I understand why you don't just go all the way and embed it in 
the Makefile.  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=, pkg/PLIST ->
pkg-plist -> PLIST=, and then every port would only be a single file.  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>.

Then you could even remove the port directories themselves except for the 
top level and save how much space?  What you're proposing is a VERY large 
infrastructure change, in my opinion.  If you're going to do it, you might 
as well go all the way and make every single port become a single PkgData
file.  Is there some reason you would stop where you did other than just to 
keep the Makefile separate?

This is a very slippery slope.  I don't think ports should be an XML package 
definition -- that's just not the BSD way.  Anything making porting more 
difficult is going to result in loss of ports developers, and I can't see 
how the proposed idea makes anything easier.  Also, what does this gain that
on-the-fly-extraction of a single ports/foo/bar/everything-but-Makefile.tbz
does not?  That seems like something far easier to do that would save even 
more space at the expense of making "cleanup" more diffiult.

If I've gotten completely the wrong idea, please explain to me what I'm 
missing.  I just feel there are more fun, pressing problems in the ports
tree to solve than space savings, and time is better spent there than saving 
disk space for what seems like the minority of ports users that do not use
packages directly.

Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green at                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\

More information about the freebsd-ports mailing list