Forcible Deactivation

Post here if you are a new Porteus member and you're looking for some help.
Full of knowledge
Full of knowledge
Posts: 2564
Joined: 25 Jun 2014, 15:21
Distribution: 3.2.2 Cinnamon & KDE5
Location: London

Forcible Deactivation

Post#1 by Bogomips » 07 Oct 2014, 00:10

Keep on meeting up with this problem of a module not being able to be deactivated, because of being required somewhere else, a case in poiint being kdelibs, where Kate needed a library which could only be found in kdelibs. Sometimes when testing for module dependency, the module, I presume, provides something which a library in nepomuk or soprano or kdelibs needs. However this library is irrelevant for installed programs on system. Disengagement of module should have no repercussions.

Another problem is where two modules are dependent on each other, but cannot deactivate both, because of interdependency. Any way possible to deactivate both simultaneously?

Is there a way to forcibly deactivate?
Linux porteus 4.4.0-porteus #3 SMP PREEMPT Sat Jan 23 07:01:55 UTC 2016 i686 AMD Sempron(tm) 140 Processor AuthenticAMD GNU/Linux
NVIDIA Corporation C61 [GeForce 6150SE nForce 430] (rev a2) MemTotal: 901760 kB MemFree: 66752 kB

User avatar
Module Guard
Module Guard
Posts: 1255
Joined: 09 Jan 2011, 18:48
Distribution: Porteus v5.0-kde-64 bits
Location: Santo Domingo

Re: Forcible Deactivation

Post#2 by wread » 07 Oct 2014, 19:12

Kdelibs is a bad example, as it is the heart of the KDE operating system; but soprano, nepomuk, pimlibs, redland, kwallet, etc, can be taken out by recompiling from source only. At least I have done it that way; you will have to edit Cmake.lists before compiling. You will have to recompile all main packages of kde: kdelibs, kdebase, kdeworkspace, kderuntime, and.., and...

I call this method "á la fanthom".

Porteus is proud of the FASTEST KDE ever made.....(take akonadi, nepomuk and soprano out and you will have a decent OS).
The Porteus Community never sleeps!

Post Reply