On Tue, 3 May 2005, Joshua D. Drake wrote:

Marc G. Fournier wrote:
On Tue, 3 May 2005, Dave Cramer wrote:

How come we have never seen anyone complain on the lists that the tarball is too big ( or have we )


Because ppl are downloading the "split distributions" instead of the whole tarball ... *every* PostgreSQL related port in FreeBSD uses the split-dists (only downloads the base and opt packages) ...

FreeBSD is a very small part of the OS planet compared to Linux and Win32.

Look at how big the Win32 installer is ;)

Agreed, but that is a binary distribution ... also, and this is based only one the impression I've gotten from the list(s), and not on actually trying it, doesn't it include 'multiple smaller packages' that you can either install all of, or pieces of?


As to FreeBSD vs Linux ... I don't have enough experience with Linux and how the packages work over there, but I don't believe that if someone were to download/package a plphp SRPM (or package) that they would include the whole 11MB tar file, would they? Or would they just package up that component which is applicable and have dependencies on other packages?

Hell, let's go at it from the other side of the coin ... you talk about how fast your connection is to download it ... but it has to come from somewhere ... which is more 'mirror friendly'? Making everyone download 11MB at a time for a, what would plPHP be, 100k directory structure, or give them a 50k compressed tar file to download to get the component they require? I'm basing that estimate on how big the existing pls are in the source tree, so I may be high/low on the real size of plphp ...

The point is that *if* something can be build using existing libraries/headers on the machine, without requiring the full source tree to build it, then providing the option to the downloader/packager/port to get the smaller piece is "A Good Thing" ... the only person that has made a compelling argument why PLs should be in the core CVS *at this time* is Tom (as regards the API changing, and its generally easier for him to modify the PLs then having the "maintainers" learn the changes), and that makes sense ... but as far as "packaging" on our end is concerned, if we can split off 'stand alone distributions', then that is what we should be looking at doing ...

Hell ... my "dream" is to see a libpq-<version>.tar.gz distribution so that I don't have to download the full server source code each time I want to install onto a client machine ... and one of these days I'll figure out how to do it ...

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED]           Yahoo!: yscrappy              ICQ: 7615664

---------------------------(end of broadcast)---------------------------
TIP 8: explain analyze is your friend

Reply via email to