Apps :: Uninstalling Apps...



ke4nt1 -

Thanks so much!!! You da man! :)

I had to reinstall Feather a fifth time (whew!) but then either apt-get installed everything or watched to see where the Feather installation scripts where pointing to.

Now I have AbiWord, Gimp 2.0, alicq, and xscanimage all working, and I am a very happy camper! :D Even though this was not a DSL-specific issue, I'm so greatful for your help! Thanks again.

Walt
walt_h{at}myrealbox{dot}com
Since there are a lot of .debs out there that break DSL, not to mention the fact thar the .dsl system is a LOT easier to use, we ought to look into reverse engineering Slackware's package management system, or perhaps using it as a template.

Slack's package management evolved from something very similar (I would imagine) to our own MyDSL system.
It's still very similar to the .dsl system. The packages are simply renamed .tar.gz or .tgz files.

Just that Slack keeps a small file for each package so that it remembers where it put everything and can remove it later.

-J.P.
The challenge comes from SAVING all the files it modifies or overwrites..

For example...

You install a big, fat, recently released .dsl app, we'll call it BigMoFo1.dsl
It updates 12 existing libs in your /usr/lib and /usr/X11R6/lib dirs.
It replaces the old gtk 2.0 with 2.4, and the perl from 5.4 to 5.8.4
And just for fun , it also overwrites several config and system files with
newer larger scripts and texts..

Now keeping a list of the contents of the .dsl file and where it installed
everything is easy..
Simply run "  tar -ztf nameofdsl.dsl > list.txt  "
Save the list...

The challenge is KEEPING all the stuff it overwrote, modified, replaced, or
otherwise tampered with, so it can return to the state it was before the
.dsl file was installed . This could be a very large cache of files and lists.

And this cache would have to be dynamic, so that when you install the
BigMoFo1.dsl , then the BigMoFo2.dsl, and the BigMoFo3.dsl ,
when you wanted to REMOVE BigMoFo1.dsl , it would KNOW what to
leave alone to support BMF2 and BMF3, while returning the remaining
files that BMF2 and BMF3 don't require back to their original state..
This gets very complicated..  This is where 'dependancies' come into play.

The system HAS to know that BigMoFo2.dsl NEEDS x,y,and z libs, etc.
and x,y,and z libs require that a,b,and c libs are in place PRIOR to installing
the x,y,and z series...  So, UNINSTALLING BigMoFo1.dsl can get to be
a very sticky situation indeed..  

My thoughts are that the myDSL system does what it was designed to do ..
and does it very well, to be such a simple installation/addon design..

73
ke4nt
Ah, yes calculating dependencies is a pain. And, honestly, for someone who wants lots of packages and a small size, an expert install of debian (using the 50mb installer cd) is really the best way to go.

But if you use MyDSL for package management, when the best way to get rid packages, a reinstall is the best way to go. Besides, even with as slow as a 16x cdrom, the reinstall takes only about 10 minutes.

I am just a little enamored with Slapt-get right now <3.

-J.P.
I think maybe there should be scripting in .dsl packages for uninstall then just like in windows you would have a dialog that you could access uninstall wizards from this would probably only cost you a couple k of mem to and would add value if it worked what do you think?
Next Page...
original here.