Date: Wed, 14 Apr 2004 14:22:33 +1000 From: Andrew Reilly <andrew-freebsd@areilly.bpc-users.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: <20040414042233.GA12776@gurney.reilly.home> In-Reply-To: <p0602040cbca10a7dbe52@[128.113.24.47]> References: <p0602040cbca10a7dbe52@[128.113.24.47]>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Apr 12, 2004 at 11:40:59PM -0400, Garance A Drosihn wrote: > [this is BCC'ed to -hackers and -arch just so everyone has a > chance to see it, but I expect the bulk of the discussion > should take place on the freebsd-ports mailing list] > > Back in January I send out a long-ish email asking for feedback > on some ideas I had for the ports-collection. I received a fair > number of comments, and have finally re-organized my ideas into > a few web pages. Hopefully these will make more sense. Sorry, I think that I missed that RFC. Many of the "files" that are to be incorporated into this scheme (particularly patches) are things that are created as separate files, and must be passed as separate files into the patch program. So to a first degree of approximation, you're building an archiver. There are several archivers in the tree already (pax, tar, cpio, (zip is in ports, too)). Why not just use one of those? All of these have command line arguments to ennumerate the elements of the archive, and to extract specific items, even to extract to stdout, if you wish to send something to (for example) patch, without recreating the original directory tree. This works fine for variable values too: just use the envdir technique: one value per file. You don't need to flinch about wasted space or inodes, becuase you don't expect these things to be extracted into real file trees (although they could be for initial compatability). e.g. pkg-descr="$(unzip -qq -c foo.zip pkg-descr)" in sh or PORTVERSION!=unzip -qq -c foo.zip env/PORTVERSION in the Makefile. (Actually, you wouldn't do that at all, you'd do something more envdir-like, to set all of the "environment variable"-like values at once.) If you go with zip, you don't even have to worry about unnecessary levels of permission, because it doesn't have that... Since space is a consideration, you do get the advantage of automatic compression. And zip is widely available as a library with an easy API, if you want to build a fancier, all-singing port-maintenance application, like portupgrade. Cheers, -- Andrew
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040414042233.GA12776>