Making programs that install themselves like a virus

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Post Reply
Message
Author
User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

Making programs that install themselves like a virus

#1 Post by 8-bit »

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.

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#2 Post by Lobster »

Good plan.

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

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

Meanwhile many thanks to all our pet creators 8)
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#3 Post by amigo »

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.

User avatar
Iguleder
Posts: 2026
Joined: Tue 11 Aug 2009, 09:36
Location: Israel, somewhere in the beautiful desert
Contact:

#4 Post by Iguleder »

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.
[url=http://dimakrasner.com/]My homepage[/url]
[url=https://github.com/dimkr]My GitHub profile[/url]

User avatar
dejan555
Posts: 2798
Joined: Sun 30 Nov 2008, 11:57
Location: Montenegro
Contact:

#5 Post by dejan555 »

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.
puppy.b0x.me stuff mirrored [url=https://drive.google.com/open?id=0B_Mb589v0iCXNnhSZWRwd3R2UWs]HERE[/url] or [url=http://archive.org/details/Puppy_Linux_puppy.b0x.me_mirror]HERE[/url]

User avatar
Flash
Official Dog Handler
Posts: 13071
Joined: Wed 04 May 2005, 16:04
Location: Arizona USA

#6 Post by Flash »

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.

User avatar
abushcrafter
Posts: 1418
Joined: Fri 30 Oct 2009, 16:57
Location: England
Contact:

#7 Post by abushcrafter »

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 :D but your probably thinking of a RoxApp :D.

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.

amigo
Posts: 2629
Joined: Mon 02 Apr 2007, 06:52

#8 Post by amigo »

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.

User avatar
8-bit
Posts: 3406
Joined: Wed 04 Apr 2007, 03:37
Location: Oregon

#9 Post by 8-bit »

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.

User avatar
Pizzasgood
Posts: 6183
Joined: Wed 04 May 2005, 20:28
Location: Knoxville, TN, USA

#10 Post by Pizzasgood »

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.
Last edited by Pizzasgood on Wed 31 Mar 2010, 01:06, edited 1 time in total.
[size=75]Between depriving a man of one hour from his life and depriving him of his life there exists only a difference of degree. --Muad'Dib[/size]
[img]http://www.browserloadofcoolness.com/sig.png[/img]

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#11 Post by sunburnt »

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.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#12 Post by technosaurus »

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
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

Post Reply