Need suggestion for PBI size

[madman]

I am creating A PBI for Monodevelop, but monodevelop requires mono,gtk-sharp,geco-sharp, and a few other packages. The mono PBI that I created, which is required for Monodevelop, is close to 50MB and I don't want to make a small PBI 10x bigger than what it has to be. What would be better? Including all of those libs in one PBI so users dont have to download and install more than 1 PBI, or have the installer check if the required binaries are there and if not then download a new PBI.
The first way would be the most correct way to create a PBI, but it would be huge.
The second way could save a lot of size but users would have to download and install additional PBI's if required binaries are missing (this can be automated).

It is not as easy as ldd'ing and executable and copying over libs, it requires full packages/programs.

[antik]

The second way could save a lot of size but users would have to download and install additional PBI's if required binaries are missing (this can be automated).

It is not as easy as ldd'ing and executable and copying over libs, it requires full packages/programs.

You can use PBI update feature maybe? Then users can download other packages later. Don't know exactly how this feature works but I think this would be interesting.

[Dingens]

mono? is this the flash rearchitecture of flash?

[pcbsdusr]

I think we need to develop a way to share PBI dependencies. (Not to confuse with system files, PBI dependencies only).

[Charles]

Or only accept Qt applications :D
Seriously, I think we need to stick with our philosophy of keeping all dependencies inside the PBI. No more dependency problem, for heaven's sake :wink:

[pcbsdusr]

i am working on that Charles :D

[TerryP]

I think we need to develop a way to share PBI dependencies. (Not to confuse with system files, PBI dependencies only).

I agree with charles.

Personally, I don't want to download openoffice. BING Dep not found please fetch PBI KMoney -> BING dep not found please fetch KOffice. Or some crap o dapo like that. (Just picked 3 office items at once there)

I could see allowing for "base system libs" that come with PCBSD not being packed in, but those are bound to change over time thus breaking the PBI.

Now this is an idea I've been thinking of after seeing over 12MB of libs needed for Ogle.

According to an e-mail from Kris the base_changes tarball is not needed. (I reckon PBI is a sort of tarball?). But why not compress the libs directory of the PBI within itself to keep space down on bigger PBI. Then untar it in the setup script.

Or would that risk file corruption to much???

[madman]

I guess then people have fast enough connections that downloading a 58MB file for a program that is only 0.8MB will not consume much time.

[TerryP]

Firefox 1.5 Windows = 4.9MB
Firefox 1.5 Linux 686 = 8.1MB
Firefox 1.5 MacOS X = 16MB
Firefox 1.5 PCBSD PBI = 18MB

Not a bad offset in this day and age. But when your talking 50-100MB before being PBI'd your talking big fat downloading a Demo kind of size.

Note: Not being a regular linux or mac user I can not say weather these install methods use sources or binaries.

What I can say, elinks wins!

Over 250MB I tend to shay away from inless it's something I want. But that's from a 125-150 Mbps DSL user who grew up on a 33.3-37.9 Kbps phone line.

[dracheflieger]

I guess then people have fast enough connections that downloading a 58MB file for a program that is only 0.8MB will not consume much time.

I didn't note any bit of sarcasm there did I Madman? :lol:

I'm far from having a good understanding of the depth of dependencies and sometime it appears that the dependency problems are as bad as ddl hell of Windows. I don't know if it's feasable but some kind of shared lib directory under /Programs (/MyPrograms) and using a shared counter flag of some sort (much like Windows, if a lib was shared with another PBI it wouldn't be uninstalled along with the executable and other support files, its tag would just be decrimented by one till at 0 it would be uninstalled) would save one much time and bandwidth costs. On the other hand, disk space is cheap but not everyone has that luxury.

I also understand that this would entail a rewrite of how PBIs are assembled, installed and removed which might lead to more problems. I assume Kris would be the final arbitrator of matters like this. Anyway, I'm butting out on this thread but just thought I'd make my thoughts known.

[pcbsdusr]

I guess then people have fast enough connections that downloading a 58MB file for a program that is only 0.8MB will not consume much time.

I didn't note any bit of sarcasm there did I Madman? :lol:

I'm far from having a good understanding of the depth of dependencies and sometime it appears that the dependency problems are as bad as ddl hell of Windows. I don't know if it's feasable but some kind of shared lib directory under /Programs (/MyPrograms) and using a shared counter flag of some sort (much like Windows, if a lib was shared with another PBI it wouldn't be uninstalled along with the executable and other support files, its tag would just be decrimented by one till at 0 it would be uninstalled) would save one much time and bandwidth costs. On the other hand, disk space is cheap but not everyone has that luxury.

I also understand that this would entail a rewrite of how PBIs are assembled, installed and removed which might lead to more problems. I assume Kris would be the final arbitrator of matters like this. Anyway, I'm butting out on this thread but just thought I'd make my thoughts known.

well, i guess that was more or less what i was talking about. Anyway, this can't solve the size of the PBI's problem as they will always have to ship with all depenedncies but it can solve the exra hard drive and Ram waste.

I'll give you a PDF when i finish writing this.

Can anyone give me ideas on how to flag a file?

I was thinking of a small text file. But as i intended to place dependencies inside "/programs/dependencies/filename+number/dependency file, maybe this could be adressed with folder permissions as dependencies would be inside a specific folder named after the name and version of the dependency...

[mal.exe]

I vote for 100% self-contained pbi. I see pcbsd as a OS of the future. And beleive me, in the near future 250mb will be absolutly nothing :P

[pcbsdusr]

ok,ok, just let me finish this at least. Everyone will be able to read at that stage and decide.

[antik]

ok,ok, just let me finish this at least. Everyone will be able to read at that stage and decide.

Not every linux game can install their own version of LCL (Linux Compat Layer) same goes for other large projects.

[tracker1]

I think that framework architectures like Java, and Mono should be exceptions to the everything and the kitchen sink PBI system... imho, they should both, along with Python, Perl, and Ruby be core supported frameworks.

In this case, you are talking about someone wanting say F-Spot, Banshee and Beagle needing over 200MB in redundant download size... I think that core frameworks (maybe not every library under the sun), should be loadable at a system level...

Also, similar use should be available for say Apache modules... PHP5, mod-mono2, etc should be loadable as extensions to a base Apache2...

The more broadly sweeping a set of libraries are, the more core it should be... Now, something that is a subset, say like the Tao library build on top of Mono, should probably go with the application...

I can see the argument against separate dependencies, but I think that frameworks like java, python, etc should be able to be dependency items.

[dracheflieger]

Good points tracker1 but there's only so much room on one CD. If it every grows to a DVD then those things may change.

[TerryP]

The only problem with DVDs is they don't work in computers with CD-ROMs and Floppy drives only :evil:


Personally I think we only got perl/python/ruby/pyqt/pygtk support out of the box because of dependancies and/or kindness :-)

[dracheflieger]

:D We just need an Al Bundy trick...fitting a size 10 foot into a size 4 shoe :D

[tracker1]

dracheflieger, I am not suggesting make it part of the install CD, but have frameworks installable as a PBI, but have the PBI install to a system, or framework tree.. this way it can be a dependency for other PBI's ... the use of such an install should probably be limited to the likes of Apache2, Java and Mono, or likewise packages that will have other packages that rely on them...

in the case of Apache2 things like PHP5 or mod-mono2 etc... for Java things like eclipse or azureus... mono could be a base for f-spot etc...

I don't think it *needs* to be on the install CD, but unlike most PBI's, should be able to be a pre-requisite for other packages.

[TerryP]

I think its a good idea with a bit of margin, stuff like Java/C# should have run time PBI and SDK type PBI and some type of IDE for those that like'em.

Such a thing would only really be useful if the whole thing was pkg_add'd or compiled any way.

[tracker1]

TerryP, yeah.. that's what I posted in another message...

mono-client (base packages, compiler and gui gtk# libraries)...

mono-server (base packages, compiler and mod-mono2, requires apache2)

mono-developer (mono-client is pre-req, adding mono-develop)

this way it's there in three packages as you mention...