Date: Tue, 13 Apr 2004 11:16:22 -0400 From: "Brian F. Feldman" <green@freebsd.org> To: Garance A Drosihn <drosih@rpi.edu> Cc: freebsd-ports@freebsd.org Subject: Re: Second "RFC" on pkg-data idea for ports Message-ID: <200404131516.i3DFGMJA078941@green.homeunix.org> In-Reply-To: Message from Garance A Drosihn <drosih@rpi.edu> <p0602040cbca10a7dbe52@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
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@FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200404131516.i3DFGMJA078941>