About large dotpups

[GuestToo]

somebody put Develop Dotpup++ for large dotpups in the Puppy todo list

i chose to have dotpup files (they are just zip files) unzip in a temporary folder in /root

(i could have used /tmp, but for many Puppy users, /tmp is ram and might, or might not, have limited space)

if you have very little free space in /root (usually your pup001 file, but /root might be in ram), then you will have very little space to unzip the dotpup file

if you have a large dotpup file, say 200 megs, it will require at least 200 megs of free space in /root to unzip, and maybe a lot more ... if the dotpup file is somewhere in /root too, you will need the space the dotpup file takes (200 megs) and the space it will take when it is unzipped (at least 200 megs, maybe a lot more)

the least space would be needed if the dotpup file was on another drive, and after it unzipped, the installer script moved the unzipped files to where they belong

i don't think you could make a dotpup system that would use much less space than this ... it is possible (easy) to cat a zip file to the end of a script or executable, but i don't think this would help much, because it has to be unzipped anyway

a simple improvement would be to allow the user to configure where the dotpup will be unzipped ... if there is a lot of space in /tmp, they might chose to use /tmp ... if there is another partition with a lot of space, they might use that partition

you can do this already of course ... just edit /usr/sbin/dotpuprox.sh and change DPDIR=/root/DotPupTmpDir

i think the only limitation to large dotpups is having enough free space to unzip them

[bombayrockers]

This is what i suggest

most of the people have pupxxx file stored on FAT partition so we can use that as the temporary folder.

Problem -> links / permissions are lost when unzipping to FAT filesystem

Solution -> Suppose there is a 200 meg install containing 10,000 files and links. At the time of making the dotpup store all the info about files in files.dat. All the links that need to be generated are coded in linkgen.sh
After the files are copied to required location use files.dat and permissions.sh to restore. Generate links using linkgen.sh

[Lobster]

somebody put Develop Dotpup++ for large dotpups in the Puppy todo list

It was me
As you know (having come up with and developed the concept) the .pups have been a great success with people using them in innovative and surprising ways. It now seems we are running programs bigger than the whole of Puppy and all his programs. Gosh!

However one of the problems and I am not sure how to address this is the resize root file system. This is not "just works" - It was 2 or three months before I realised this had / could be done.

The problem is do you check available disk size at bootup and offer an upgrade - do we make it an option as part of each 10th bootup?

In itself there is nothing wrong with people using big programs - yes, yes we would all prefer small but I will not be handing in inkscape so I can use sodipodi and if we want other large programs?

So it would seem that dotpup could (as one solution) check the available size that Puppy has and also the estimated size of the decompressed file and offer a link to resizing if required?

What are your thoughts here GuestToo? Any other ideas? You seem to be suggesting the existing .pup is OK. Maybe we should just use gzip or unleashed? Or again maybe a script that calls the dotpup and also handles the size situation?

[Guest]

permissions and symlinks was one reason i did not have the dotpup file unzip to the folder that the dotpup is in ... using /root was a simple way to be sure it did not unzip on a vfat file system ... the simplest way i can think of to workaround a limited tmp space problem is to use /root by default but allow the user to also configure where the tmp space is located

G2

[Guest]

i don't think automatically resizing a pup001 file is a trivial thing to do ... things can easily go wrong and data can be lost ... i don't like automatically editing menus and pupget config files for the same reason (a dotpup could accidently stop pupget from working is it does not work quite right)

G2

[aahhaaa]

it seems to me that this is also a question about how Puppy will grow up...

is Puppy a Von Neumann machine that spreads & replicates Linux?

is Puppy a distro that, particularly by its size, keeps older machines alive?

is Puppy the '3rd party app' that allows integration of most other Linuxware?

I'm not against it, but if big add-ons become the rule, what is the essence of Puppy? Will it eventually become just another big distro?

[Nathan F]

Maybe we should just use gzip or unleashed?

The situation is about the same with unleashed as far as large packages go. An unleashed tarball will be placed into /root/.packages and then untarred there as well. The script then moves the files to the proper place before deleting the tarball and temporary directory. If someone is installing a package locally the situation can be worse, as they would probably have downloaded the package to somewhere in /root too. Barry has even added a warning to the Pupget script that tells you to resize /root before trying to install OpenOffice, as the temporary storage will need too much room.

I think that anything really large is a better candidate for a squashfs than a dotpup or unleashed package. One problem is that now it's looking like some people are going to want more than one usr_more.sfs, and there's currently only provision for one (I can't imagine wanting to run both KDE and OpenOffice from Puppy but there have already been inquiries about doing just that). But it's still way better than the situation with the really large dotpups.

I really don't think that Puppy will ever become a large and bloated distro, at least as long as Barry handles the official releases. Puppy105 actually came down in size almost ten megabytes from the previous vesion, and is just as useful. I think that the Puppy foundation has a good handle on what Puppy is all about and will do a good job of keeping it that way when Barry does step aside. The large packages we're talking about here are all addons, and I don't see anything wrong with that.

As for how Puppy will grow up, I've been under the impression for a while that it had already.

Nathan

[Flash]

it seems to me that this is also a question about how Puppy will grow up...

is Puppy a Von Neumann machine that spreads & replicates Linux?

is Puppy a distro that, particularly by its size, keeps older machines alive?

is Puppy the '3rd party app' that allows integration of most other Linuxware?

I'm not against it, but if big add-ons become the rule, what is the essence of Puppy? Will it eventually become just another big distro?

A small kernel which integrates many large applications seems to me to be a desirable specification for an OS. The trick is to decide what should be in the kernel so that it can control different applications and provide the services to them that an OS needs, or is expected, to provide.

It seems to me that the true kernel of the OS would be pretty useless without what amount to some basic apps, which are usually compiled with the kernel for the sake of convenience but are not actually part of the kernel itself. For the sake of purity these could be left as separate applications to be added later.

What I'm trying to get at is that I believe the Puppy a la carte model is the way to go. You only download the applications you want, along with Puppy itself, which need not be very large if properly designed for the job of controlling and integrating those applications.

[Pizzasgood]

i don't think automatically resizing a pup001 file is a trivial thing to do ... things can easily go wrong and data can be lost ... i don't like automatically editing menus and pupget config files for the same reason (a dotpup could accidently stop pupget from working is it does not work quite right)

G2

Also, it would be annoying, and I might not even want it resized in the first place. Maybe I only want a 256 megabyte pupfile, and have it crammed full. Every ten boots, it will bug me about updating it. And if it automatically updateded it, I'd get mad and break my cd, because I don't want anything automatically screwing with my pupfile, and I don't want it bigger.

As for usr_more.sfs, I think the best thing to do would be make it recognize the user_more_ prefix, then you could have several. You would still be limited by loop devices, though.