Date: Mon, 8 Jul 2002 00:32:20 -0700 (PDT) From: Doug Barton <DougB@FreeBSD.org> To: Mark Valentine <mark@thuvia.demon.co.uk> Cc: Garrett Wollman <wollman@lcs.mit.edu>, <arch@FreeBSD.org> Subject: Re: Package system flaws? Message-ID: <20020708001921.C2247-100000@master.gorean.org> In-Reply-To: <200207080714.g687EH6t047234@dotar.thuvia.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 8 Jul 2002, Mark Valentine wrote:
> > From: Doug Barton <DougB@freebsd.org>
> > Date: Sun 7 Jul, 2002
> > Subject: Re: Package system flaws?
>
> > One of the reasons I suggested the "compress the binaries, then compress
> > the metadata plus binary tarball" method is that it is more space
> > efficient.
>
> 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) 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. Assuming that we use the most efficient means
possible to compress the binaries (and by binaries I of course mean "what
the package is designed to install") then it's not going to compress
further, no matter what method we use to squish the two together.
> It isn't _all_ about space (but space helps a lot).
Don't underestimate this factor. Pushing the packages out to ftp-master
from bento is already a limiting factor on how often we can update the
package set. We also have to take foreign mirrors, and users who pay for
every byte they download into account.
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.
> 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).
Doug
--
"We have known freedom's price. We have shown freedom's power.
And in this great conflict, ... we will see freedom's victory."
- George W. Bush, President of the United States
State of the Union, January 28, 2002
Do YOU Yahoo!?
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?20020708001921.C2247-100000>