yum remove package (dependency problem)

[glaskoncILLa]

libnetfilter_conntrack postoji kao paket..

[pingu]

libnetfilter_conntrack postoji kao paket..

U pravu si, probao sam ručno instalirati, ali ne pomaže. I dalje tupi po svojem:

iptstate-2.2.1-5.fc11.x86_64 from installed has depsolving problems
--> Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed)
Error: Missing Dependency: libnetfilter_conntrack.so.1()(64bit) is needed by package iptstate-2.2.1-5.fc11.x86_64 (installed)

[DoDo]

Ajd obriši ovaj iptstate pa probaj iznova.

[Grof]

Tebi jednostavno treba ovaj plugin za yum:

Kod: Označi sve

yum install yum-plugin-remove-with-leaves

Description: This plugin removes any unused dependencies that were brought in by an install but would not normally be removed. It helps to keep a system clean of unused libraries and packages.

I nakon toga će raditi ono što želiš

[pingu]

Ajd obriši ovaj iptstate pa probaj iznova.

Kada obrišem iptstate, yum update je uspio, samo što sada sa iptstateom?

Tebi jednostavno treba ovaj plugin za yum:

Kod: Označi sve

yum install yum-plugin-remove-with-leaves

Description: This plugin removes any unused dependencies that were brought in by an install but would not normally be removed. It helps to keep a system clean of unused libraries and packages.

I nakon toga će raditi ono što želiš

Hvala.

[4ndY]

Suko, hvala što si me spomenuo, no nažalost, mislim da ne znam kako efikasno riješiti taj problem.

Odnosno, ne znam kako općenito riješiti taj problem i da li je uopće načelno moguće riješiti. Ako netko drugi nudi tu mogućnost (npr. apt-get, yum-remove-with-leaves ili package-cleanup --leave) sigurno to ne može učiniti "ispravno" (ako može, volio bih da me netko ispravi i objasni kako to radi).

U čemu je problem: dependencyji nekog paketa nisu isključivo vezani za taj paket, već oni mogu:
a) biti depdendencyji i drugim paketima koji su instalirani
b) nuditi sami korisniku neku funkcionalnost (ili direktnu ili kao "dependency" za neki ručno buildani softver)

Pretpostavimo da program uklanja sve dependencyje koje je instalirao program kojeg uklanjamo, osim onih koji su u međuvremenu postali dependencyji nekog novoinstaliranog programa. To je ok "način" funkcioniranja za slučaj (a), ali teški promašaj za slučaj (b).

Zašto? Recimo ja na netinstall Fedore ukucam npr.:

Kod: Označi sve

yum install kde-desktop

što mi jasno povuće kao dependencyje i X-e i valjda još 300MB dependencyja. Recimo da sad uklonim KDE, ali bih htio nastaviti koristiti X-e jer ću recimo ručno kompajlirati xmonad, no X-i su mi dependencyji KDE-a pa će i njih ukloniti (da bi ih onda opet ručno instalirao?!).

Evo jedan konkretan primjer gdje "package-cleanup --leave" nije pametan - predlaže mi da maknem pakete s fontovima jer više nema OOo koji bi ih koristio, ali ih ja želim nastaviti koristiti u Inkscapeu.
Drugi primjer: imam vlastitu skriptu koja koristi CLI "cdrecord". Uklanjanjem k3b-a bih izgubio i cdrecord i funkcionalnost svoje skripte.

Po meni jedini dobar način je da ti package manager čita misli.
I uvijek ostaje ručno i sporo, ali "pametno" rješenje: yum.log.

[DoDo]

U čemu je problem: dependencyji nekog paketa nisu isključivo vezani za taj paket, već oni mogu:
a) biti depdendencyji i drugim paketima koji su instalirani
b) nuditi sami korisniku neku funkcionalnost (ili direktnu ili kao "dependency" za neki ručno buildani softver)

Pretpostavimo da program uklanja sve dependencyje koje je instalirao program kojeg uklanjamo, osim onih koji su u međuvremenu postali dependencyji nekog novoinstaliranog programa. To je ok "način" funkcioniranja za slučaj (a), ali teški promašaj za slučaj (b).

Zato apt-get ima to jako lijepo riješeno tako da za svaki instalirani paket čuva flag koji kaže je li paket instaliran kao dependency ili ne. I ako je instaliran kao dependency, a ne želite ga obrisati sa autoremove, onda morate pozvati apt-get install paketa, iako je on već instaliran, samo da ga autoremove ne bi pobrisao. Ta mi se filozofija sviđa, iako sam često imao probleme kao u slučaju b) citiranog posta dok nisam još znao za taj flag...

[glaskoncILLa]

postoji dirty fix za to sa kombinacijama dpkga i apt-geta/aptitudea, naravno sistem ce biti broken, tako da to nije bas rjesenje nego workaround sto sam koristio kod nekih instalacija iz sourcea gdje sam zelio noviju verziju nego onu sto se moze dobiti u paketima, a za koje je trebalo puno dependencya koje bi trebalo instalirati iz sourcea ili provesti stoljece da saznam kako se zovu u paketima. e onda fino instaliras aplikaciju iz paketa, ona povuce dependencye, maknes aplikaciju, ostavis pakete, stavis ih na hold i instaliras ponovo noviju verziju aplikacije iz sourcea.

ali da, nema sretnog rjesenja, ovo gore je vrlo dirty, korisiti u slucaju krajnje nuzde sa iznimnim oprezom, ali teoretski bi mogao ostaviti x-e.

a naravno postoji i apt-get moo, vrlo korisna stvar.

[pingu]

To zavisi od distribucije i kako je posloženo. Paket menađer treba pratiti situaciju. U jednostavnijem slučaju bi mi trebao ponuditi mogućnost brisanja mogućih dependecya a ne da ih tražim ručno ako se već ne može posložiti neka automatika. Ove primjere koje si naveo. Npr. ukoliko instaliram OOo, paket menađer vidi recimo da prije toga nema tih font paketa u /var-u, prema tome, može zaključiti da pri deinstalaciji OOo-a može slobodo maknuti te font pakete. Ili te upita da li može obrisati te fontove.
Isto tako K3B je samostalan program, a cdrkit cdrdao dvd+rw-tools se moraju posebno instalirati. Kao što sam rekao, zavisi kako se to posložilo u distri.

edit:
Vidim da je DoDo stavio vrlo dobar primjer.
Isto tako, X su dio Xorg paketa ili ne? Što ima kde-base sa X-om?

[4ndY]

Isto tako K3B je samostalan program, a cdrkit cdrdao dvd+rw-tools se moraju posebno instalirati. Kao što sam rekao, zavisi kako se to posložilo u distri.

edit:
Vidim da je DoDo stavio vrlo dobar primjer.
Isto tako, X su dio Xorg paketa ili ne? Što ima kde-base sa X-om?

K3b je zapravo samo malo napredniji GUI za cdrecord i sl. CLI alate. Isto kao što kde-base ne radi bez X-a (pa mu je X dependency).

Ovo što je DoDo napisao je logičan i jasan pristup u većini slučajeva, ali se totalno skrši na ovakvim, rijetkim slučajevima gdje ti je potreba samostalna funkcionalnost dependencyja. Jer, kome će pasti na pamet da ćeš micanjem XYZ paketa ostati bez wgeta ili tar-a

A da na svako uklanjanje dependencyja odgovaraš s Y ili N - to bi te tek ubilo.
Mislim da je čitanje misli jedini ispravni pristup