Mit tegyek, ha valamit nem találok meg a tárolókban?

Mit tegyek, ha valamit nem találok meg a tárlókban? Megvan, de nem az a verzió ami nekem kell?
Sejthető, hogy az elsődleges válaszom az: gondoljuk át valóban szükség van arra a programra?
Nincs olyan helyettesítő program, ami a tárolókban ott van és natívan tudunk letelepíteni? Illetve át kell(ene) gondolni, hogyha újabb program verziók után vágyódunk, akkor valóban arra a program verzióra, arra a funkcióra, arra az újabb lehetőségre van-e igényünk, tényleges igényünk, vagy csak egyszerűen viszket a kezünk, hogy frissíteni kéne.

Miért nem kell a legfrissebb programverzió feltétlenül?

Én megfigyeltem saját magamon, hogy a legújabb program verziókat elsődlegesen fel szoktam rakosgatni. Mert azok a legújjjjjabbbbb funkciók nélkül én nem tudok élni, legalábbis elméletileg. Gyakorlatban kiderült, hogy bár nagyon szépek azok a funkciók, de kilencven százalékához hozzá sem nyúltam. Azaz tetszik, tetszik nagyon, nagyon jó, de igazából nem hasznos számomra. Miért? Ha fejlesztés van, az nem feltétlenül azt jelenti, hogy számunkra is fejlesztik azt a programot, mármint az én igényeimnek, elvárt munkafolyamatnak megfelelően fejlesztik. Természetesen nem feltétlenül fogjuk használni azokat a funkciókat, lehetőségeket, amiket eddig sem használtunk.

A frissítés fontos dolog, de ne azért történjen meg, mert valamit elgondoltunk, hogy az számunkra nagyon jó, hanem azért történjen meg, mert azt a funkciót használom.

• A biztonsági frissítéseket mindig meg kell tenni. Itt térnék ki arra, hogy a régebbi verziójú programokhoz is érkeznek biztonsági frissítések, azaz nem azt jelenti, hogy a tízes a tizenegyesre léptetve kapjuk meg csak a biztonsági, tehát a biztonságot érintő frissítéseket, hanem - legalábbis a legtöbb rendszerben - a régebbi program verziókhoz is. Amit az adott disztribúció ad azokhoz automatikusan megkapjuk a biztonsági frissítéseket, és ez nagyon fontos dolog, hiszen sokan azért ácsingóznak a legújabb verziókra - tehát a legeslegeslegújabb verziókra, - mert ők azt gondolják csak abba vannak meg azok a biztonsági frissítések, ami fontos a gépek biztonsága érdekében. Nem, nem így működik. Vannak 3, 5 esetleg hosszabb ideig támogatott disztribúciók, az úgynevezett LTS disztribúciók, amik az sokéves programokhoz is elkészítik a biztonsági frissítést, és ezen a téren nem kerülsz hátrányba ezekkel sem!

Korrekt megoldások: Appimage, Flatpak, Snaps

Ha az előbbieket átgondoltuk, és mégiscsak az újabb verziót szeretnénk beszerezni, ami nincs meg a tárolóban, vagy olyan programot szeretnénk telepíteni, ami nincs meg a tárolókban, akkor több lehetőségünk van. Minden esetben, - és szerintem ez nagyon fontos: minden esetben át kell gondolni ezt a sorrendet, - a sorrend amilyen telepítési metódusok között választhatunk.
Olyan legyen, hogy a legkisebb, a rendszert érintő műveletek legyenek benne. Azaz az új program felrakása ne érintse - vagy csak minimálisan - az eredeti rendszerünket!
Miért? Mert esetleg kiderülhet, hogy mégse nem kell az a verzió vagy esetleg kiderülhet mégse kell az a program, mert nem azt csinálja, nem úgy csinálja..., ahogy én szeretném, akkor azt el kell távolítani. Jellemzően az ilyen plusz telepítések nem a rendszer által adott csomagkezeléssel, hanem egyéb metódus mentén szoktak megtörténni. Ezeknél a teljes körű eltávolítás nem feltétlenül történik meg olyan egyszerűen, mint ahogy a csomagkezelő letörli az olyan csomagokat, amiért ő felelős.

Én úgy gondolom, hogy első lépésben az appimage csomagot lenne érdemes megkeresni. Ennek több oka van.

• Az egyik oka az, hogy az appiamge csomag olyan telepítés, hogy jellemzően - nem mindig, de jellemzően - hozza magával az összes függőségét, azaz jó eséllyel futni fog a te gépeden. Függetlenül attól, hogy éppen milyen disztribúciót, vagy annak a disztribúciók melyik verzióját használod.
• A másik talán az egyik legfontosabb ok, hogy az appimage csomag jellemzően egy darab fájl, amit futtathatóvá teszünk és használjuk. Ez nagyon kényelmes abban az esetben, hogyha el akarjuk távolítani: semmi olyan függősége nincs, ami esetleg fent maradna. Két lépésben tudunk eltávolítani egy appimage csomagot. Az első lépés természetesen az appimage törlése, majd rákeresünk a program nevére keresővel a fájlrendszerben és az esetleges könyvtárakat, amiket elkészített a működéséhez, töröljük.
• Sok programkészítő már appimage csomagban terjeszti a programját. Kényelmes, több verziót tarthatunk a gépünkön, és akár napi szinten készülhet új, a napi fejlesztéseket, hibajavításokat tartalmazó állomány. Így különösebb kockázat nélkül próbálkozhatunk.

A másik két általánosan használható, nagyon kezes disztribúció független megoldás telepítésre a flatpak és a snap rendszer. A legtöbb disztribúció támogatja ezeket, vagy ezek közül az egyiket. Bár sok kritikát kap mindkettő és érzelmeket kavarhat a snaps használata, de a fenti esetekben jól működnek.
Mindkét rendszer ismert, a használata egyszerű. Több disztribúció már a grafikus szoftverkezelőjébe is beépítette. Így nem térek ki ezekre, csak mint lehetőségét említettem meg.

Biztos út a rendszered szétbarmolására

A probléma akkor van, amikor ezek a csomagkezelő rendszerek appimage, snap, illetve a flatpak nem tartalmazza azokat a programokat, amiket fel szeretnénk rakni. Illetve nem azt a verziót támogatja.
Ebben az esetben általában elkezd az ember keresgélni az interneten, és megdöbbenve látja, hogy a konkurens disztribúciók bizony ott van csomagban. Ez elindítja azt a gondolatot, hogy bár nem javasolt, de esetlegesen át lehetne alakítani egy RPM csomagot Debian csomagba, vagy fordítva. Esetleg egy Arch csomagot át lehetne barkácsolni Debian rendszer alá. Erre van lehetőség, de én mindenkit lebeszélek róla. Gyakorlatilag egyrészt elég nagy munka, és nem biztos, hogy értünk hozzá.
Másrészt nem feltétlenül fog rendesen működni.
A lehető legrosszabb megoldás ha egy idegen csomagot kicsomagolunk, kitömörítünk és elkezdjük bemásolgatni a megfelelő könyvtárakba a fájlokat, és azt gondoljuk, hogy ez így működni fog. Kisebb csomagnál esetleg. Egy-két fájlt tartalmazó csomagnál ez működik, de a rendszert érintő dolgoknál vagy komolyabb, több függőségét érintő csomagnál ez nem fog működni, maximum szétbarmoljuk a már működő rendszerünket azért, hogy egy programot kipróbáljunk és okosabbak legyünk, mint a disztribútor. Ezt a megoldást mindenképp kerülni kell. 

Rendszerhez készült független csomagok

Több programkészítő előre összecsomagolja egy szabvány telepítő fájlba a programját, és így adja nekünk át. Gyakorlatilag a legtöbb általam ismert ilyen oldal például az ocenaudio nagyon szépen kilistázza azokat a verziókat, disztribúciók és lehetőségeket, amihez ő elkészíti ezeket a csomagokat. Általánosságban ezeknek a csomagoknak a telepítése annyira biztonságos, mint a közreadó megbízható. A programozónak, programnak tehát érdemes egy picit utánaolvasni.
Mennyire biztonságos? Nekem jó tapasztalataim vannak. Azt kell mondanom, hogy különösebb probléma ezzel nem volt. A másik probléma, - illetve nem is probléma, mert már volt róla szó - az ilyen egyedileg telepített egy-egy csomaggal, hogy azokat nem frissíti a rendszer automatikusan, hiszen nem a tárolókban van a program. Nem kap a disztribútortól folyamatosan frissítést, így ezt nekünk manuálisan kell megcsinálni. Említettem: érdemes ciklikusan megnézegetni az így feltelepített programok honlapját, és ha kell frissíteni.
A nagyobb probléma az, hogy az emberek ezeket a egyedileg elkészített független programokat nem feltétlenül tudják jól kezelni.
"Telepíteni" mindenki tud. Általában a telepítés annyi, hogy letöltöd, rákattintasz és elindul a grafikus felület vagy a megfelelő parancssori parancsot kiadod és utána már fel fog települni a program. Ez nem okoz gondot! A gondot az okozza, hogy az emberek általában azt hiszik, hogyha egy programcsomagnak az a vége, hogy .deb, azaz Debianhoz készült az mindenféle Debian származékos disztribúciók jó lesz. Itt fel kell hívnom a figyelmet, hogy bár a kiterjesztés és a csomagkezelés is ugyanaz, de nem feltétlenül lesz jó egy Debianhoz készült csomag a Linux Minthez. Vagy esetlegesen a Linux Minthez készült csomag az MX Linuxhoz.
Mindegyik Debian ősökkel rendelkező rendszer. Hasonlóképpen az Ubuntu, a Linux Mint, MX Linux és egyéb Debian alapú disztribúciók csomagjait nem szabad összekeverni.
Beszéltünk arról, hogy ez nem egészséges, azaz minden esetben meg kell nézni, hogy egy általános Debian csomagot kapunk, ami minden rendszerhez ez jó, vagy oda van írva, hogy például a Linux Mint huszonegyeshez készült, vagy az Ubuntu akármelyik verziójához. Van esély, hogy keresztben ezek működnek, telepíthetőek lesznek, de van arra is esély, hogy nem. Jó esetben rögtön jelez a telepítőrendszered, a csomagkezelő, hogy itt bizony kielégítetlen függőségek vannak, nem tud telepíteni. Azt is megbeszéltük már az elején, hogyha ilyen jelzés van, hogy függőségek nem jók, meg egyéb panasz, akkor nem letiltjuk a függőségek ellenőrzését, hanem megoldjuk a problémát.
Rosszabb esetben, bár erre kicsi az esély, hogyha szabályosan járunk el, esetlegesen ezek a programok magukkal cipelnek olyan függőségeket vagy felülírnak olyan programkönyvtárakat, amit a rendszer saját maga akar kezelni. Eltérő verziószámuk van, eltérő elnevezésük van, vagy eltérő lehetőségeket adnak a programoknak. Azaz az ilyen letölthető független csomagokkal mindig óvatosan bánjunk és figyeljük meg, hogy az adott saját disztribúciónkhoz készült avagy nem? 

Futtatható állományok, előre fordított csomagok 

Mindenki találkozott már olyasmivel, hogy egy kiszemelt program előre lefordított futtatható állományban érkezik. Ilyen az általam egy régebben bemutatott fájl átnevező, fájlnév rendező programocska, ami bizony futtatható állományban is elérhető.
Ezek általában működnek. Nyilván, hogyha valami függőségi vagy egyéb problémájuk van, nem fognak elindulni. Azaz indításkor, kipróbálás mindig terminálból indítsuk el és nézzük meg a panaszokat, sirámokat hogyha vannak. Esetlegesen azokat meg lehet oldani, ha mindenképp kell a program.
Maga a használata önmagában nem okozhat gondot, hiszen vagy elindul, vagy nem indul el, nem telepíthet fel semmit. De kifejezetten oda kell figyelni, hogy ezek minőségét, illetve biztonsági szintjét senki nem ellenőrizte.

Ha megbízol a programozóban, - mint az előbb említett programnak a programozójában én megbízok, - akkor ezeket nyugodtan lehet használni. Ha nem, akkor ne használd őket. A rendszerre ezek alapvetően nem veszélyesek, jellemzően nem tudnak felülírni semmit és kényelmes megoldások.
Itt is ki kell emelnem: ha probléma van azt meg kell oldani, de a probléma megoldás ne érintse nagy mélységben a rendszeredet, azaz fontos rendszerkönyvtárakat, programokat ne írjál át, ne barkácsold össze és vissza a rendszeredet. Inkább mondj le az adott program használatáról. Jellemzően ott van probléma, ha vagy a program régebbi - mert nem nézted meg hogy mikori - és lehet hogy 15 éves. Azóta a Linuxnak sokféle szabványa megváltozott. A másik probléma point ennek az ellenkezője. A program nagyon új. Az új Linux rendszerekhez készült, te pedig esetleg a Debiannak vagy akármilyen ilyen, "maradibb", hagyományosabb disztribúciót használsz és akkor már a program újabb könyvtárakat, újabb szabványokat vár el és bizony a te rendszered erre már nem alkalmas. Ilyenkor is érdemes lemondani a program használatáról, nemhogy a rendszeredben belenyúljál. Ez nagyon fontos tényező: egy program futtatásához, ha az nem létszükséglet, nem feltétlenül kell rendszerszintű műveleteket (barkácsolást) elvégezni. Olyan, esetleg általad nem is teljesen megértett műveleteket, telepítések, fájlok manuális cserélése, linkelése stb. nem feltétlen ajánlott. A program nélkül meg tudsz lenni, de a rendszeredet összebarmolod, akkor nem fogsz tudni azzal dolgozni! 

Ha sokszor beleütközöl ebbe a hibába, akkor nem jól mérted fel a neked való Linux disztribúciót, és túl lassan frissülőt választottál. Ami alapvetően nem gond, mert sok olyan disztribúció van, amiben van teszting, unstable és hasonló frissebb csomagokat adó megoldás. Itt sem a tárolók keverése, hanem a teljes átállás a megoldás. Senki nem azt várja el egy kezdőtől, hogy elsőre megtalálja a neki való kényelmes Linux disztribúciót megtalálja.

Kisebb csomagtelepítők: pip3, npm stb.

Bár kevésbé ismert, de sokszor nagyon jó megoldás az ilyen kisebb, jellemzően programnyelvekhez kötött megoldás. Ezek közül talán a legismertebb a pip, vagy a pip3, ami a Python nyelv telepítője.
Ha valóban nincs más megoldás, akkor ezeket kényelmesen használhatjuk. Pár esetben csak ezekkel lehet felrakni egy kisebb programot.
Milyen előnye van ezeknek? A legnagyobb előny, hogy a legtöbb nem nyúl a rendszerfájlokhoz, így a telepítéssel érkező függőségeket felrakja, de nem írja felül a már meglévő csomagokat, amikre a rendszerednek szüksége van. A másik előnye (ami sajnos sok esetben igaz): csak ezzel megy fel valamilyen kisebb program. A legnagyobb előnye szerintem mindenkinek ismert már: ezek rendszerfüggetlenek, bármelyik Linux disztribúcióban jól üzemelhetnek. A programozónak nem kell sok telepítőcsomagot elkészíteni, csak egyet. Ez kisebb, kevésbé közkedvelt, de hasznos programoknál nagyon nagy előny.
A hátránya is egyértelmű: ezek sem frissülnek a disztribúcióval. Így adott két feladat: a manuális frissítés módját meg kell keresni, majd az ciklikusan elvégezni.
Egy - szintén ismert - tipp: ha van lehetőség, akkor csak a saját felhasználónknak telepítsük, így biztosan nem érint rendszerszintű dolgot. Csak akkor kell sudo jogot elővenni, ha a sima telepítés nem megy. Mindig figyeljünk arra, amit a készítő leír, a lépéseket pontosan be kell tartani.

Saját fordítás

A legvégső, de talán a legösszetettebb megoldás. A forráskódból elérhető (ez gyakorlatilag a Linux stb. alá írt programok nagy része) programokat mi is összeállíthatjuk: "lefordíthatjuk". A megoldás nagyon jónak tűnik, de csak a legvégső esetben használjuk, amikor már teljesen tisztában vagyunk a hatásaival.
Az egyik legfontosabb figyelmeztetés: felhasználó programokat lefordítva jellemzően nem lesz problémánk a rendszerrel, mert a legtöbb esetben ezek nem nyúlnak rendszerszintű állományhoz. De ha egy rendszert érintő elemet akarunk lefordítani, akkor már vizsgálni kell a következményeket. Simán felülírhatunk fontos állományokat, beállításokat és azokat visszaállítani már nem lesz egyszerű.

A fordítások összetettek, de ha a lépéseket betartjuk, akkor jó eséllyel a program le fog fordulni és települni fog. Három összetevőre kell nagyon figyelni. Az egyik a program programnyelvéhez tartozó fordító programcsomagok teljes körű telepítése. Nem ritka a fórumokon olyan kérdés, hogy XYZ program nem fordul le, mi a hiba. A válasz a kimenetek vizsgálata után: nincs telepítve a kellő és fordítást végző csomag. Ami nagyon kínos lehet a kérdezőnek, mert egyértelműen rámutat: el sem olvasta a leírást. Itt azt írtam, hogy "teljes körű". Érdemes lehet az összes ajánlott, javasolt függőséget az első fordításkor felrakni. Ha nem kell egy fordítóhoz tartozó programocska, akkor maximum a helyet foglalja, de ha nincs fenn és egypár oldalnyi hibakimenetet kell átkínlódni, akkor az felesleges időtöltés.
Majd fontos lépés a fordítás előtt az összes, a fordítandó program által elvárt függőség telepítése. Itt áll meg a legtöbb esetben a lendület, hiszen sok függőség is kellhet, amelyet nem feltétlen találunk meg a tárolóban. Ilyenkor a függőségek felkutatása és lefordítása komoly feladat lehet. Nemhiába találták ki a disztribúciók csomagkezelését... Gyorsabb, hatékonyabb és biztosabb Linux telepítést tett elérhetővé az ötlet.
Ezután más csak a programot kell lefordítani. Ami alapvetően egyszerű, a legtöbb esetben pár sor beírását kívánja a terminálba. Ami nagyobb probléma: bár mindent jól csináltál, de mégsem fut le hiba nélkül a fordítás, nem készíti el a megfelelő programot. Nem meglepő, ha hosszabban kell a hibakimeneteket olvasgatni. de az sem, ha a felét meg sem érti az ember. Ezek jellemzően nem olyan lépések, amiket egy középhaladó felhasználónak találtak ki!
Tipp: ha nagyon sok ilyen helyben fordított program kell, akkor érdemes lehet az AUR-ban, az Arch linux tárolóban körbenézni. Ha ott megoldást találsz, akkor válaszd az Arch alapú disztribúciók egyikét.
Ehhez kapcsolódó tipp: ha valaminek a lefordításával nem jutsz dülőre, akkor is érdemes az AUR-ban keresgélni, és az ottani állományba belenézni. Ezek a legtöbb esetben sima parancsállományok, amik az Arch alá elkészítik a programot. Esetleg ezt tanulmányozva kapsz olyan gondolatot, amivel telepíteni tudod a programodat.

Ha kezdő vagy, és nem technomágus, akkor érdemes minimalizálni a fordításos programokat. Bár nagyon profin hangzik, hogy ha nincs más, akkor fordítsd le forrásból, de ez valóban egy profi megoldás.

"Hivatalos" csomagkezelő és a fordítás

Amit érdemes tudni: van olyan csomagkezelési megoldás, ami maga fordítja le az állományokat. Ilyen az AUR (de van pár kisebb is) tárhely nagy része. Csak egy szkriptet tartalmazó fájlt kapunk, amit futtat a csomagkezelő és maga intézi a dolgokat. Erről volt már szó, így csak jelzem, hogy ezek a fordításos megoldást használják. Mindenhol ajánlják, de kevesen teszik meg: ha ilyent használsz, akkor nézz bele a szkriptbe. Bárki, bármit beleírhat egy ilyen telepítő szkriptbe. Bár ritka a problémás megoldás hiszen sokan használják ezeket, azonnal jelzik a hibát, de soha nem árt az óvatosság! Illetve ezek közt is lesz régi, elavult, ami nem fut le rendesen.

A másik teendő: eltörlés

A telepített programok egy részét el szeretnénk távolítani.
Jogosan kérdezed meg, minek erről beszélni, hiszen ott a grafikus program, ami a telepítésrét felel, ott van, hogy törlés. Ennyi.
Sajnos nem!
Az eltörlésnél nem fogja a telepítős, csomagkezelős program leszedni minden olyan eszközt, fájlt, könyvtárat és átállított konfigurációt, amit felrakott és beállított. Ez nem olyan egyértelmű, mint ahogy én azt gondoltam. Menjünk végig pár olyan lépésen, amit érdemes logikusan átgondolni, hogy ne barmold össze a rendszered.

Hogyan távolítsunk el egy programot?

A kérdés nem kérdésese: szabályosan! Igen vonalasan és mereven tartsd be a szabályt: amivel felraktad, azzal szedd le! Ne barkácsolj, nem gányolj! Az nem megoldás, hogy ha valami program nem kell, akkor fogod és fájlkezelőben kitörlöd a könyvtárát!
Azaz első lépésben a csomagkezelőben ismerd meg (ha lehet) a parancssoros eltávolítás módszerét. Ha ez nem tetszik, egyes lépést megtehetsz a grafikus felületen is, de párat nem tudsz. Ha csak annyit tartasz be, hogy a csomagkezelődet használod telepítésre és eltávolításra, akkor nagy hibát nem véthetsz! Ha más kicsit jobban benne vagy a Linux használatában, akkor érzed: ez jó, de nem teljes megoldás.
A legtöbb csomagkezelőben pár dolog alap eltávolítás esetén hiányos. Az egyik, hogy sokszor fenn marad olyan függőségként felkerül fájl, amire nincs szükség, illetve fenn maradnak beállító állományok, könyvtárak stb. Ezeket el kellene távolítani. Ilyenkor jön a képbe a leírások olvasgatása: mindegyik csomagkezelőnél van egy erőteljesebb eltávolítási metódus, amit jellemzően parancssorban kell megadni. Ez eltérő lehet (purge stb. néven), de leszedi a felesleges függőségeket, illetve valami szinten a konfigurációs állományokat is. Ez jellemzően biztonságos, és kényelmes. Már az ilyen megoldással sokat teszel a rendszered tisztasága érdekében. Így - ha eddig nem ismerted - akkor most keresd meg az ilyen kapcsolódat. Ugyanez igaz a flatpak és a kisebb csomagkezelőknél emlegetett dolgokra is. Alapból az eltávolítás még nem feltétlen eltörlést jelent!

A végleges eltörlés

Ha annyit teszel, amit írtam: megismered a csomagkezelési törlés és purgálást, akkor teljesen jó vagy! Ha tovább akarsz lépni, akkor már sokkal jobban oda kell figyelned és az óvatosságot is elő kell venni.
A fenti purgálás sem mindig elég és sok esetben maradhatnak fenn olyan program függőségek amikre nincs szükséged. Ezeket hol jobban, hol kevésbé, de az alap purgálás is leszedi, de pld. Debian alatt, flatpak alatt bizony maradnak nem használt (unused) akármik. Bár kenyeret nem kérnek, de több-kevesebb helyet azért elfoglalnak, illetve szemétként is értelmezhetjük őket. Ezekkel kell valamit tenni! Itt is igaz a legalapvetőbb Linuxos titok: el kell olvasni a leírást és ott benne lesz! A Debian alapokon az autoremove kapcsolót fogják írni, de a többin is megtalálható valami formában ennek az analóg eszköze. Keresd meg - most - és használd!

Mi az ami miatt az odafigyelést emlegettem? Ezek nem annyira megbízhatóak, mint ahogy azt gondolnánk. A csomagkezeléstől függően jobb-rosszabb megoldások léteznek. A műszaki hátérre nem szeretnék kitérni, de tudni kell: nem biztos, hogy ha ezek valamit "árva" vagy "unused" csoportba raknak és törölni akarnak, azt jó ha le is szedik!
Amikor lefut a parancs és kiírja a listát, amire úgy gondol, mint törlendő - néz meg azt! Ha van benne olyan, amiben bizonytalan vagy, akkor ne engedd törölni. Saját példa: simán leszedte az összes XFCE állományt egyszer a tisztító program, mert az gondolta róla, hogy azok feleslegesek! Kétszer nézd meg a kimenetet, majd inkább lépésenként töröld le amire nincs szükséged, ellenőrizve minden lépést. Macera! Az, de ha belebarmol a rendszerbe a törlés, akkor az nagyobb gubanc lesz.

Jó eséllyel a fenti módszerekkel a program részek el lettek tüntetve. De mi van a többivel? Beállító állományok, esetlegesen létrehozott könyvtárak stb. ezzel nem feltétlen tűnnek el. Bár szintén igaz, hogy ezek jellemzően kicsike tárhelyet foglalnak el, de bosszantó, ha folyamatosan felesleges alkönyvtárakba, vagy konfig állományokba botlunk. Ezeket érdemes eltüntetni. bár folyamatosan találni olyan programot, ami azt mondja magáról, hogy ezeket a felesleges állományokat leszedi, de olyant, ami teljes szolgáltatást nyújtana, olyant még nem találtam.
Nincs más út, csak a manuális megoldás: valami módszerrel a program nevére rákeresünk és a nem kellő állományokat kézzel töröljük. Ez egy biztonságos megoldás, hiszen egyesével dönthetünk a törlésről.

Miért hagyja fenn pár csomagkezelő a konfig állományokat?

Jogos a kérdés, de jogos érveket kapunk válasznak. Mert ezek olyan állományok, amiket egy későbbi újratelepítés használhat. Ha már belenyúltunk egy-egy program beállításába, akkor nem feltétlen jó, ha a munkánk elveszik, ha a programot leszedjük egy újratelepítés előtt. Több csomagkezelő ezt elég összetetten kezeli, mert a régi konfig állományt átnevezi, és hagy döntési lehetőséget az usernek a választásra. Korrekt megoldás.