04

February
2013

Delete .sb file on deactivation or not?

I noticed several comments regarding the 'feature' that Slax deletes the .sb module file on deactivation. Currently it works this way, since module is automatically downloaded (created) on slax activate, so it's also deleted (destroyed) on slax deactivate. The situation is a bit different if you deactivate the module by giving full path to the .sb file as a parameter, in that case the file is kept.

Some users may activate modules which they downloaded beforehand and they do not like the module file to be deleted on deactivation. At the same time they do not like to use full path to the module file as a parameter. So I'd like to ask you here for your opinion regarding this.

I think that at some point Slax should delete the module file on deactivation, especially if it was activated online (downloaded automatically to /slax/modules/). The reason for that is if the module is not deleted, then it will get activated the next time you boot. I think it is correct to delete it in this case.

Do you think that the correct behavior should be different? Should Slax somehow remember what modules were downloaded automatically and delete only those, while keeping the others? Or do you think that sufficient solution could be to delete only module files if they reside in /slax/modules/ on the USB disk, or in /mnt/live/memory/modules/ in memory, but preserve them if .sb files are in any other locations?

User comments
lainme 2013-02-04 03:56

Probably move the deactivated modules to another directory?

jcsoh 2013-02-04 04:13

(a) Ask the user if they want to delete the file (assuming this is easy to implement)

(b) Leave it but show a message that the bundle is not deleted ,any the user (if desired) must delete it themself.

rahrah 2013-02-04 04:40

I'd agree with jcsoh but b) would be my first choice, followed by a).

Villain 2013-02-04 05:55

I propose that you create an additional designated temporary modules folder, to better distinguish between temporary and persistent modules, and then set up the different slax commands as follows:

slax activate: activate module only for the running session; download to temp folder if necessary, or load it from a local filesystem if a path is specified.
slax deactivate: just deactivate & keep the file. If it's in the designated temp folder, it'll be gone upon reboot anyway. If it's anywhere else (such as modules/), it'll be kept.
slax install: put module in modules/ folder & activate it. Move it there from the temp folder if it's already activated, otherwise download it.
slax uninstall: deactivate & remove the file

Mark De Silva 2013-02-04 06:02

I'd prefer the old Slax way. Just unmount the loop device holding the module content and leave it as that. The physical module can be kept where ever it was activated from.

Or introduce a '-d' / '--delete' option to 'slax deactivate' for deletion:

slax deactivate --delete module1.sb

Makes it easier for users to alias the 'slax deactivate' to just 'deactivate' too.

Thiago Silvino 2013-02-04 06:20

You could umount the module and move the .sb file to another directory let's say /tmp/deactivated or the user could pass a parameter to deactivate and delete the .sb file.

kaiomatico 2013-02-04 08:06

I also think jcsoh's thinking is the right way to do it

+1

Manfred 2013-02-04 09:19

I tend to be on Jcsoh's side but I think 'deleting or not deleting' should
follow the fact whether the system has been started with or without
saving changes.

People like me who start Slax without saving changes trust on the system being started each time in the same way unless they manually save bundles
in the bundles folder on the media.

Those who start the system with saving changes trust on the fact that
bundles which have been deactivated will not be activated and bundles
which remain activated during shutdown will be activated on next boot.

Tomas M 2013-02-04 11:16

Activation is like 'installing' the software, and deactivation is like 'uninstalling'. On every other distro you would expect the software to be completely removed during uninstall. Why is it such a big problem here with Slax? :-)

Moving the file to a temporary directory will make it consume space (or RAM memory if Slax is started without persistent changes) even while the sb file is no longer used. Imagine 150MB module still sitting in RAM somewhere ...

It seems to me we are all talking about different circumstances here. Where do you actually get the module from when you need it kept (not deleted) during deactivation? Did you download the module to /root/Downloads? Is it not lost already when you activate it anyway? (since it moves somewhere outside the aufs union). Why do you need to keep it while you are 'uninstalling' the software? Where do you need to keep it? In /mnt/live/memory/modules/?

I mean, I am trying to understand your real needs here, and why you have them. Thank you for your replies.

Jcsoh 2013-02-04 11:55

" Why is it such a big problem here with Slax? :-)"

Because slax is a unique case since it is a frugal /live mode. In most traditional linux distro /real mode , the only way to have software is to actually install it (with the software actually been written to the media) . They have no other other choice. If they don't like it , they are force to go thru uninstallation which may still leave residual files /traces.

In slax the "installation " is actually in 2 parts:-
(a) Downloading
(b) Activation (nothing is actually written to the media if changes is not save)
(c) Deactivation
(d) Delete /Remove module

Problem is , if the user like the software , then they assumed it will be there the next time.

So basically , they do not equate activation = installation /deactivati0n=uninstallation.
n
But rather activation=start / deactivation=turnoff
So user do not expect turn off means the programme is gone/deleted.

Turnoff simply mean stop the programme and should not include deleting it. Hence and extra step should be required if user really want to delete the module.

Wizard57M 2013-02-04 13:00

I created an "optional" directory in my Slax tree, and in this
I keep modules that are not used each time I boot Slax,
but may be needed after starting up. Perhaps a prompt
for user input at time of "deactivation" asking them if they
want to keep the module or delete it from their Slax media
(most of the time I run from a USB thumb drive with changes
saved).

Manfred 2013-02-04 16:02

>> On every other distro you would expect the software to be completely
>> removed during uninstall

No, I'm expecting that the INSTALLED software has been removed from the
system but that the underlying package gets handled in the way my
package manager has been configured: to keep a package in cache after
it has been installed or to delete it; e..g. have a look at the configure options in /etc/slackpkg/slackpkg.conf from slackpkg included in slax.

"grep -B1 DELALL /etc/slackpkg/slackpkg.conf

# If DELALL is "on", all downloaded files will be removed after install.
DELALL=on"

The other package manager I'm using (slapt-get) has the same logic.

Perhaps it may help if you think about what the programmers intention was
when he integrated the optional folder in Slax5/6 ;)

I am using it for software I don't need at every boot but which I don't want to
be downloaded before use. Thus I can activate it even if I'm offline.

In my opinion the lack of this folder/function in Slax7 is the main reason for
the 'to delete or not delete' discussion.

Even in times when smartphone/tablet users are online 24/7 there are use
cases for Slax7 to be able to activate software in offline mode.

Just my 0.02$

Manfred 2013-02-04 16:35

...another important fact (at least for me) is:

As long as I don't need it, keeping documentation, man pages and devel
components is kind of wasting space but if I need them I have to break
Slax's bundle management by installing the original package over software
having already been activated before.

>> On every other distro you would expect...

...that there is a bundle_name.{doc,devel,man} bundle splitted from the
original package which I can install when it is needed like I am able to in
Debian, Ubuntu, SuSe, Fedora, Arch and so on.

Only Slax (among those which count) deletes them and leaves me stuck.
Even the core locale files in a Slax7 version which is promoted to 'speak
my language' have been deleted without the chance to get them back
in another way than to reinstall the whole original package.

Imho when creating a localized Slax version you should use a 'localepurge'
function in a chrooted environment like those 'other distris' do. This way
you can be sure that all locales needed for that language are present.
Localepurge can be adapted to Slax/Slackware environment in an easy way.

Mark De Silva 2013-02-04 20:52

+1 @Manfred's last 2 posts

Most importantly, if I download a software, try it and then later uninstall it, I don't expect the installer/uninstaller to remove the installation package that downloaded. No distribution of any OS I know of does that.

Right now i've just modified the slax script's deactivate function to just leave the sb package where it is. Logic entails - if the module was downloaded to the live system, it will be moved to /mnt/live on activation and after reboot it will be gone. If it was downloaded to a non-live partition, after a reboot it will still be there so I can choose to activate it again if I want to.

David Stegbauer 2013-02-04 23:32

I can imagine several use cases, for which different behaviour may be evitable. In any case I would welcome to have explicit option to not delete the module file, for example:
slax deactivate --keep module

Use case: run Slax completely from RAM, boot media disconnected
Expected behaviour: "slax decativate" drops the module completely.
Explanation: no need to keep module in ram.

Use case: run Slax from read-only boot media
Expected behaviour: "slax activate" first tries to locate the module in special directory on the media (say /slax/repository), else it downloads it from internet
"slax decativate" just unmounts the module if it comes from media, or drops it completely if downloaded (to free the ram).
Explanation: User may want to have "pre-downloaded" modules and activate them easy way (e.g. for offline use). In the same time there is no obvious place where to store downloaded module to.

Use case: run Slax from writable media
Expected behaviour: "slax activate" first tries to locate the module in special directory on the media (say /slax/repository), else it downloads it from internet.
"slax deactivate" just unmounts the module and moves it into that special directory (if it is not already there).
Explanation: User may want to have "pre-downloaded" modules and activate them easy way (e.g. for offline use). There also is obvious place to store them. Management of the "repository" is completely up to the user.
Note: It would be nice if availability of newer module version is checked during activation and user is offered to replace the older one.

David Stegbauer 2013-02-04 23:43

Sorry for my english: evitable -> welcome. So the first sentence should be "I can imagine several use cases, for which different behaviour may be welcome"

parrothead 2013-02-05 01:16

I vote for deactivate not deleting any bundles by default. I use Slax as my primary OS at home. This is a laptop, to which I boot Slax from USB, always using toram and never using changes. My USB install is fairly small, basically 6.1.2 with some KDE files saved so the apps that I frequently use are opened in the same location, as well as WPA settings, the omnibook kernel module loaded so ACPI functions, etc. But I have a large number of modules stored in a directory on the laptop's hard drive, but don't necessarily have many activated at a time. I have some small scripts, usually called load_*, e.g. load_mame, load_amarok, etc. which activate the various modules necessary for those applications, maybe create some links, etc. The modules are either ones I've built myself, ones automatically converted by Tomas from Slackware packages, or ones built using Slack Build scripts. If I deactivate these modules later, I certainly don't want the files deleted from my hard drive. :)

Sponge Bob 2013-02-05 01:18

+1 David S.

A local repo which is checked first would be a very elegant way. Aditionally it can cut the cost and time of downloading. Also a great place to store personal/unofficial bundles.

ojowinter 2013-02-05 02:55

Currently I confirm which Module is activate in Slax Software Center. But I'd like to see it like "slax list" command. I think simply solution that deactivate module is just add prefix _. It's easy works with dolphin. and useful when module backup to other remote or local storage.

Behind the times 2013-02-05 03:20

Activate = Install
Deactivate = Uninstall
Simples... ;-)

Great little distro Tomas

Villain 2013-02-05 04:28

"Activation is like 'installing' the software, and deactivation is like 'uninstalling'. On every other distro you would expect the software to be completely removed during uninstall. Why is it such a big problem here with Slax? :-)"

Because that's untrue. If, in Slackware, I download a *.txz, install it with installpkg, and later remove it with removepkg, I still expect the *.txz to be exactly where I put it.

Tomas M 2013-02-05 05:19

@Villain: the difference in Slax is that if you download a .sb module and you install it using 'slax activate', you no longer have the .sb module, since it gets moved outside the union, else it couldn't be activated at all.

TJ 2013-02-05 05:35

Hi Thomas

You need to Create new feature in your blog similar to Facebook questions just "yes" or "no" instead cracking your head.

no offence to anyone.

Kadalka 2013-02-05 09:18

I didn't read what other people writes before...

1/ When we download something it is to be stored not to be deleted.
2/ When something is to be installed it should be taken from a place, then the files should be put where they should be.
The packages won't be deleted at all...
3/ When someone would like to uninstall just the files are deleted, *IF* it is allowed, not the packages at all...

4/
This said some features should exists:
default behaviour must be: NO deletions at all. Just the files could be deleted... [those that should be uninstalled]
options must be at least:
a) ask people to delete the packages
b) delete when possible [dependencies checking] with questions about dependencies [packages that need this, other packages needed by the package to be installed]
c) keep configuration files...
d) delete without questions... [force]

Tomas M 2013-02-05 20:21

@Kadalka: you have poor understanding of how Slax activates modules. There are *NO* files at all _installed_ anywhere during module activation.

Mark De Silva 2013-02-06 01:38

I think what Kadalka is trying to say is that the content of the modules that is overlaid onto the base slax during the activation should be un-overlaid (?) while the actual slax bundle (.sb file) is retained where ever it was initially stored (so long as its not in the union). For want of a better word/phrase, the term "installed" is used.

Kadalka 2013-02-06 07:11

@Tomas M

Read MarkDS talk...
I know how slax activate runs...
(AUFS, loop device and so on)

I want you to know that I am not angry about what you said.
I thank you because may be some people may think that some files ARE installed...
We all know that none is installed (NO COPY).

@MarkDS
1/ --- "For want of a better word/phrase, the term "installed" is used" [...]
Exactly.
Some people told me that they do not want any Linux to run in their system because they don't want anything to be installed...
I just answer that LINUX Live CD do not install anything.
This is the reason why I've said that NOTHING must be mounted.
(Especially NTFS devices)

2/ You do understand as always what I've said.
What you said and do to the slax, porteus and slackware area is ALWAYS appreciated.

Thanks.

Kadalka 2013-02-06 07:14

I've said this:
--- "This is the reason why I've said that NOTHING must be mounted." [...]
TO be precise :
Slax and derivatives must NOT mount anything.
Those who do want to mount something should do that EXPLICITLY.

Crashsite 2013-02-06 15:48

I like David suggestion above. Keep a repository or local copy of any downloaded module. This way, activating them would not "move" them, but "copy" them outside the union.

Mocabilly 2013-02-07 10:48

I quickly read the posts in this tread and have one argument left for the "do not always delete the modules" side of this discussion.

Network traffic (to the Slax server) - it will increase as more people will start using Slax and extra modules..

As mentioned before, people with minor knowledge of Slax inner workings will assume that "deactivate" will just temp. "disable" a module. (They do Not even start thinking about what happens when one "deactivates" a module)

I strongly belief that people will deactivate (resource hogging) modules when they experience that Slax is starting to "slow down", that they Do re-activate some modules (prob. those "big" modules) when they need one of those "big" modules again..

It may already been pointed out, but, this is my 50 cents

nick99 2013-02-08 10:47

1.ask whether to deactivate
2.if yes
2.1ask whether to backup module to another folder
2.1.1 if yes back up module.
2.1.2if no delete module directly from the bundles
folder.


simple enough...

California Bob 2013-02-08 14:21

Use "activated.txt", a list of files that should always be loaded at boot.

If you want to always boot with a module you just downloaded and tried out, then add that module to activate.txt. If you're tired of a module or want to replace it with something better, just remove its entry from activate.txt.

Mocabilly 2013-02-09 03:46

@California Bob
I think working with a list is sort of a hassle, unless it would be integrated in the module manager.

But then again, you're moving even further from the "single-click-program-installation-idea".

Users want plain, clear and especially short interactions with programs that handle installation, configuration, removing, maintenance, ...

California Bob 2013-02-09 05:57

@Mocabilly:

Yeah, it would require a change to the scripts to use the listfile. I guess that also means putting a "manage apps" button on the desktop for people migrating from Android ;-)

Seriously, my suggestion was motivated by my agreement with your earlier comments about reducing network bandwidth.

Mark De Silva 2013-02-09 23:36

Its simple enough, whatever is downloaded by the users to their disk space, should never be deleted by slax unless the users specifically do so themselves. So that means implementing a switch or option that allows users to initiate the delete process, by default it shouldn't delete.

Vytor 2013-02-10 03:46

Good Morning Thomas,

+1 Mark De Silva last comments:

[ Its simple enough, whatever is downloaded by the users to their disk space, should never be deleted by slax unless the users specifically do so themselves. So that means implementing a switch or option that allows users to initiate the delete process, by default it shouldn't delete.]

Answering your question as why to keep .sb file upon deactivation? Well why not make it a user's choice. If the user runs out of space or system is slow or anything else it is the user's responsibility to have deleted the .sb file himself /herself.
OR --
You can can have slax deactivate script check if installed from a special "protected area /folder" like example My-Slax-Downloads folder if installed/activated from that folder then .sb file is kept and if not then.sb file is deleted.

What do you think?

Regards,
Vytor

saneone 2013-02-12 12:26

Thomas,
I only use old Slax 6.1 on regular basis and have not used Slax 7 bundles yet. My opinion is based on what I have seen from old Slax. Old Slax module choice to activate or download from website:
1. Download (aka local activation) should be under my control and not deleted upon deactivation.
2. Activate (remote activation) can be safely deleted when deactivated because I chose to activate remotely and not locally.

I run Slax from my flash drive and keep my own so called repository (as mentioned above) and only activate software as I need it (activate to ram actually, so I can unmount and remove my flash drive). Basically I use activate/deactivate as in load/unload and not install/uninstall. My reason is because I use the copy to ram feature and only load minimal modules on boot with the option to activate anything else as needed. I don't use the persistence feature on my flash drive, if I need to save any changes made, I just save those as a new module and load on next boot.

pirraste 2013-02-14 01:09

I agree with Mark:
activation -> download + mount
deactivation -> unmount (optionally moving it)
module manager "purge" option -> deletion

My two cent :)

Shahab Rezaee 2013-02-18 12:42

Have an offline cache would be worthy, specially for users with poor internet connection. Using symlinks, we could easily manage modules:
1. Downloaded modules stores in a cache directory like /slax/mcache.
2. Activated modules have a symlink in /slax/modules. So, for deactivating modules, manager just deletes the symlink.
3. Add a delete option to manager for deleting a module from cache.
4. Add a download option to manager to download a module without activating that. (Optional)

David Forsyth 2013-03-16 10:52

Ha! I never used the activate feature. I always download the module first, copy it, and then activate the copy. If I like it I put it in the modules folder on the boot media.

My eeepc has plenty of (upgraded) memory but a very slow CPU. So I don't have to shuffle modules in and out of memory even though I load Slax to ram every time. My problem is stripping needless chrome out of things to speed things up.

People with the opposite situation probably would want the module deleted upon activation and the files purged upon deactivation. I would expect that is more common.

RĂ´mulo GuimarĂ£es Vieira da Silva 2014-03-08 06:28

Hi Tomas, I'm new in here but anyway I want to collaborate with the Slax dev.
In my oppinion, the module should be deleted just in the case it was download online, using slax download or slax activate and it generated a pre-requisite to download something. In the other cases, the file could be stored in a backup folder in /slax/modules/deactivated for example.