Date: Mon, 8 Jul 2002 15:55:38 +0100 (BST) From: Mark Valentine <mark@thuvia.demon.co.uk> To: Doug Barton <DougB@freebsd.org> Cc: Garrett Wollman <wollman@lcs.mit.edu>, <arch@freebsd.org> Subject: Re: Package system flaws? Message-ID: <200207081455.g68Etclk063764@dotar.thuvia.org> In-Reply-To: Doug Barton's message of Jul 8, 12:32am
next in thread | raw e-mail | index | archive | help
> From: Doug Barton <DougB@freebsd.org>
> Date: Mon 8 Jul, 2002
> Subject: Re: Package system flaws?
> On Mon, 8 Jul 2002, Mark Valentine wrote:
> > Compressing the "metadata + binary tarball" just lost you the ability to
> > access the metadata without uncompressing the whole caboodle.
>
> Well, if people are dead set on having both things in the same package (I
> still think two seperate files is a cleaner solution)
My earlier suggestion actually said just about the same thing, with the
_option_ of storing the two (or more) parts in an uncompressed archive
instead of a directory, for ease of handling.
In light of Wes' comments on storing the metadata, I'd modify my examples
as follows.
Example 1: simple package, not sub-packaged.
$ ls /var/spool/pkg/foo-x.y
base.bz2 package.xml
Example 2: package with optional development and documentation components
$ ls /var/spool/pkg/bar-m.n
base.bz2 devel.bz2 doc.bz2 package.xml
(In an archive, of course, package.xml would be the first member.)
> then as long as the
> binaries are compressed efficiently (using tar + bzip or some such) then
> we can use a less efficient, though more friendly alternative to compress
> the metadata + binary bit.
Bingo!
> > It isn't _all_ about space (but space helps a lot).
>
> Don't underestimate this factor.
I should have said a _lot_. ;-)
> There is also another reason to consider seperating the binary tarball and
> the metadata that I haven't mentioned yet. And actually, now that I think
> of it more it's another good reason to seperate the two things into
> different files. If I have package A that depends on package B, under the
> current system if we up the version of package B, we have to re-roll
> package A altogether just to update the dependency data, even though
> nothing about the binary has, or needs to change. By seperating the
> metadata and the binaries we can just update the metadata with the new
> dependency and push just that.
Indeed.
> > See my earlier suggestion which was basically "compress the binaries,
> > then _archive_ the metadata plus binary tarball".
>
> Sorry to say I skimmed that too rapidly. It sounds like we agree roughly
> on this point, although I'd love for us to use a non-GNU tool for this
> (sorry, blatant prejudice there).
Ideally you use POSIX archive formats and any tool which implements them.
Cheers,
Mark.
--
Mark Valentine, Thuvia Labs <mark@thuvia.co.uk> <http://www.thuvia.co.uk>;
"Tigers will do ANYTHING for a tuna fish sandwich." Mark Valentine uses
"We're kind of stupid that way." *munch* *munch* and endorses FreeBSD
-- <http://www.calvinandhobbes.com>; <http://www.freebsd.org>;
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200207081455.g68Etclk063764>