(old)Puppy Linux Discussion Forum

I think that any program that is made should be made so that files and changes it makes can be removed by either an uninstall program or through use of making a PET package for the program.
Any program that makes modifications to files should include an uninstall script that will remove said modifications and restore the modified files to their previous condition.

I would expect program installation behavior like that from windows.
But this is linux and an installed program should not do a bunch of file modifications without a simple means of removal and restoration.

I have expressed my opinion on this.
It is also a reason we basically stopped using PUP packages in favor of PET packages for the ease of removal.

Good plan.

Look forward to you going around to each existing pet
and repackaging with an uninstaller where not available

Hope that was the intention . . .
or perhaps what should happen?

Meanwhile many thanks to all our pet creators

The ability to do this requires a sane package format coupled with a complete package manager -the two are intimately bound. Puppy still does not really have either one of these.

Bad idea. That requires you to keep the package, so you have the package itself and the installed contents. If gzip compresses it to 30%, you have 130% of the package's original size. That's BAD.

Another point, all packages will share lots of code, that's not efficient.

Files installed can be removed but modifications made to files that are not in package (made by pinstall.sh) can't be restored and I don't see any package format that will be able to do this. Simply try not to package with pinstall.sh script and all other files can be removed by package manager. If you don't trust packages extract them then manually copy to system after inspecting package contents. I think package format is fine the way it is now.

There's something called an application in a directory that might be a better idea. I forget the details, but basically it's just a directory you put anywhere you want, which contains the application program with all its dependencies and so forth. To uninstall the program you simply delete the directory. I think I've seen at least one application program for Puppy that's done this way.

Flash wrote:There's something called an application in a directory that might be a better idea. I forget the details, but basically it's just a directory you put anywhere you want, which contains the application program with all its dependencies and so forth. To uninstall the program you simply delete the directory. I think I've seen at least one application program for Puppy that's done this way.

That's called a PortableApp but your probably thinking of a RoxApp .

Can we focus though on the original post of this thread please. Which was a moan (Hope you don't minded that I call it that.) on packagers keeping to standards which I agree on or at least mention that there is no uninstall script when one is needed! Before any one moans at me yes I know (a very small amount though) that packaging is hard as I have some goods to upload.

The package manager should be able to remove or update a package. To do so, it must know which fiels were installed by the package. It should also preserve any installation scripts so that it can (possibly) undo actions performed by it upon installation -such as removing links created by an install script.
Tghe utility of having a package manager remove everything installed by a program is debatable. For instance, a program installs a conf file. You edit the file to suit your needs. Do you really want to lose those customizations if the program is uninstalled? Probably not -you might re-install and want to use your old conf file. For this same reason, conf files should usually be handled in such a way, on installation, that your sutomized files will not be overwritten.
Package managers should also check for 'overlap' -that is, if a package installs a file which is also contained in another package, removing one of the packages should not remove the duplicated file.
A package manager should also allow for upgrading packages, by understanding version and release/build numbers.

Well, let us say that the installed package writes modifications to your initrd file. Upon removal of the package, the modifications are still there.
So maybe a warning to back up said file in case you want to remove the package and have your initrd file as it was before the install.

Oh, I know how to get around this.
Never install anything. Just use Puppy as it comes on the CD.

What package modifies the initrd.gz? No packages should do that automatically, because the location is not standard and even if it was, it may be on a read-only partition. (Like a CD!). If it came from a CD it might not even still be in the drive and mounted.


@Iguleder: No, you wouldn't have to keep the package. Only a list of the files that were installed, and a copy or diff of the ones that were modified. Saving a copy of the install scripts would also be good, but not manditory, as long as you save the changes that the install scripts make. But scripts are small and compress very well (they are text), so saving them would be fine. Especially since the vast bulk of Puppy packages should not have any install scripts.


@8-bit: Reversing modifications is not trivial, unless you assume that the user will make no changes and that the packages will be removed in the same order they were installed (at least where overlap is concerned). Otherwise, what do you do if three packages all modify the same line of a configuration file, and you want to uninstall the second one? There is now way for the script to know what it should do. It can only guess, which is worse than doing nothing (unpredictable behavior is worse than bad but predictable behavior).

This is why I prefer to see packages that simply don't modify anything. The situation has improved over the years. Packages used to have to modify /etc/rc.d/rc.local, /etc/profile.local, and ~/.xinitrc to have themselves autorun, or to have environmental variables they need set. But now they can just place a file in /etc/init.d, /etc/profile.d/, and ~/Startup/. Much easier to deal with from a package management standpoint.

Also, moving from dotpup, which was script based, to .pet, which is mostly handled by the package manager, was a major improvement. Not being required to mess with an install script makes people much less tempted to add scripted steps. Now doing that would involve going out of your way to create an install script.

I would like it even more if the .pet format were broken into two formats: .pet, and .pets, where .pets can have an install script. The .pet would be strictly copy only, no install scripts at all. That way people can see at a glance what kind of package they're getting, especially if the file icon were changed for .pets and a warning displayed on installation that a script was being run. In fact, a warning could be done with the current .pet implementation, and it could even have a button to let the user read the script before authorizing it to execute.

EDIT: Of course, there would ideally be an option to tell it not to bother you with those messages, for the people who don't worry about it.

Statically compiled SFS files basically do this, they contain all the files for the app.,
except for the settings files that are usually in /etc or /usr/etc, but can be anywhere.
If only writable settings files are outside of the SFS file, then it`s a snap to clean it up.

Again... SFS files don`t clutter the file system with loose files that are a nightmare!
Also it`s almost impossible for SFS files to get viruses, but it is possible...
If the app. becomes corrupt, just replace the SFS file. No searching for the bad files.

magic ermine does all of this even for shared libs - but you have to specifically tell it not to package libraries that you expect to be on the system (gtk etc...) otherwise you get a huge package full of shared libraries. I have tested it in 421 and it worked pretty well - abiword as a single file executable

http://puppylinux.ca/members/T/Ermine_Apps/
puppy
linux