Dependency hell

[Croga]

Sinds een aantal jaartjes draai ik mijn eigen web-/mailserver. Eerste op Windows met Lotus Domino maar later de avontuurlijke stap naar Linux genomen. ClarkConnect mee gestart, nu draaiend op ClearOS6 (Een CentOS gebaseerde distro).

In de loop der jaren ben ik steeds meer thuis geraakt in Linux en dus ook wat meer functionaliteit toegevoegd zoals Sickbeard en SABnzbd. Die laatste is nu, waarschijnlijk, de bron van mijn hoofdpijn.

De laatste tijd merkte ik dat ClearOS niet meer automatisch update. Dus ging ik naar de command line om eens te kijken wat er mis ging.
Mijn "yum update" werd beantwoord met: (een hele stapel tekst die neer komt op)
"Protected multilib versions: nss-softokn-freebl-3.14.3-10.el6_5.x86_64 != nss-softokn-freebl-3.14.3-9.el6.i686"

Uiteraard heb ik eerst de suggesties die yum geeft geprobeerd:
- yum update --skip-broken geeft hetzelfde resultaat
- rpm -Va --nodigest --nofiles doet niets
- yum update --exclude nss-softokn-freebl.otherarch geeft hetzelfde resultaat

De volgende tip die ik vondt was om het package wat je eventueel niet nodig hebt te verwijderen. Dus met yum remove gekeken of één van de twee te verwijderen is. Conclusie:
nss-softokn-freebl.x86-64 zit zo'n beetje in alles wat je kunt bedenken. Eindresultaat was een foutmelding dat yum weigert yum te verwijderen
nss-softokn-freebl.i686 zit in SABnzbd (en nog twee anderen). die wil ik dus ook niet kwijt.

Een zoektocht op deze melding leverde mij alleen een bericht van een andere ClearOS gebruiker op die het probleem oploste met.... yum update

Zijn er nog andere opties die ik kan proberen?

[Sallin]

Ik draai geen yum based package management systeem, maar wat je eventueel kan doen als je zeker bent dat het probleem bij SABnzbd ligt is SABnzbd verwijderen, installatie updaten, SABnzbd opnieuw installeren.

Alternatief is een poosje (week / twee weken) wachten totdat er een update komt die je dependency repareert.

[Hero of Time]

Zulke dependencies zouden bij een distro als CentOS eigenlijk niet voor moeten komen. Gebeurt het toch, dan moet er iets aan de hand zijn met je repo's. Omdat je twee extra pakketten hebt geïnstalleerd, heb je er ook repositories meegeleverd gekregen? Zet die dan uit en voer de update nog een keer uit.

[Croga]

Sallin schreef op dinsdag 27 mei 2014 @ 15:13:
Ik draai geen yum based package management systeem, maar wat je eventueel kan doen als je zeker bent dat het probleem bij SABnzbd ligt is SABnzbd verwijderen, installatie updaten, SABnzbd opnieuw installeren.

SABnzbd verwijderen doe ik liever niet. Dan kan ik helemaal opnieuw beginnen met configureren en dat is niet zomaar effe gedaan. Het draait nu zoals het hoort, afblijven dus.
Daarnaast is het natuurlijk geen oplossing. Iedere keer dat een update niet werkt een pakket opnieuw installeren is geen houdbare oplossing.

Hero of Time schreef op dinsdag 27 mei 2014 @ 15:17:
Zulke dependencies zouden bij een distro als CentOS eigenlijk niet voor moeten komen. Gebeurt het toch, dan moet er iets aan de hand zijn met je repo's. Omdat je twee extra pakketten hebt geïnstalleerd, heb je er ook repositories meegeleverd gekregen? Zet die dan uit en voer de update nog een keer uit.

Daar had ik nog niet aan gedacht.... SABnzbd heeft inderdaad zijn eigen repo. Helaas heeft het verwijderen daarvan niets opgeleverd. Ook zonder de repo van SABnzbd blijft de foutmelding hetzelfde.

[Sallin]

Croga schreef op dinsdag 27 mei 2014 @ 15:30:
[...]

SABnzbd verwijderen doe ik liever niet. Dan kan ik helemaal opnieuw beginnen met configureren en dat is niet zomaar effe gedaan. Het draait nu zoals het hoort, afblijven dus.
Daarnaast is het natuurlijk geen oplossing. Iedere keer dat een update niet werkt een pakket opnieuw installeren is geen houdbare oplossing.

Ik neem aan dat je een backup kan maken van de configuratiefile(s). Ik neem ook aan dat het niet gebruikelijk is dat je in de problemen komt.

Wat ik nog weleens doe met Debian Testing wanneer er af en toe een pakketje bijvoorbeeld niet goed multiarc ondersteund is alleen dat pakketje niet updaten (op Hold zetten) en nagaan of ergens een maintainer het probleem heeft gevonden en aan een oplossing aan het werken is. Het langste dat ik heb moeten wachten was een paar maanden. Er was verder ook niets kapot, alleen dat pakketje kon niet worden bijgewerkt.

[Croga]

Sallin schreef op dinsdag 27 mei 2014 @ 15:59:
Wat ik nog weleens doe met Debian Testing wanneer er af en toe een pakketje bijvoorbeeld niet goed multiarc ondersteund is alleen dat pakketje niet updaten (op Hold zetten) en nagaan of ergens een maintainer het probleem heeft gevonden en aan een oplossing aan het werken is. Het langste dat ik heb moeten wachten was een paar maanden. Er was verder ook niets kapot, alleen dat pakketje kon niet worden bijgewerkt.

Maar dan de hamvraag: Hoe zet ik een pakketje "on hold"? Ik ben het met je eens dat yum simpelweg alles behalve die nss-softokn-freebl mag updaten maar dat krijg ik ook niet voor elkaar.

[_eXistenZ_]

Bij het removen van je SABnzbd verdwijnen niet ineens maar je config-files hoor, en anders even een tar trekken van je /etc/, dan kan je het later zo weer terugzetten.

[CAPSLOCK2000]

Ik heb dit soort problemen verschillende keren meegemaaatk, oa omdat de schijf vol zat en een keer omdat ik m'n systeem rebootte terwijl de updates nog liepen. Dan is het x86_64 versie van een pakket wel al geinstalleerd maar de i686 versie niet. Ik heb ook erg veel moeite gehad om er weer vanaf te komen.
Als je het nog niet geprobeerd hebt, doe dan eerst een 'yum clean' om alle oude caches op te laten ruimen.
Als je een klein aantal pakketten hebt dat voor problemen zorgt kun je de juiste versie's van de RPM's downloaden en met de hand installeren.

[Croga]

yum clean hielp ook niet.

Uiteindelijk was mijn conclusie dat het dependency op de 32-bit versie zat dus heb ik hem "setopt=protected_multilib=false" verteld (waarvan gewaarschuwd wordt dat de 32-bit dan kapot zou kunnen gaan; don't ask me how) en dat heeft het geheel weer op gang gebracht.

CAPSLOCK; het probleem is niet zozeer dat er een klein aantal pakketten voor problemen zorgde; er was maar één pakket wat voor problemen zorgde. Het probleem was echter dat yum update helemaal niet meer liep.

Afijn; eind goed al goed maar damn sure de reden dat je op een Linux server niet teveel verschillende taken wilt draaien en ook damn sure een reden voor mij om terughoudend te blijven.

[Hero of Time]

Red Hat based distro's (dus ook CentOS en Fedora) zetten multilib standaard aan. Dat kan voor problemen zorgen zoals je gemerkt hebt, maar helpt wel bij het installeren en draaien van 32 bit applicaties. Je hoeft geen extra config toe te passen hiervoor. Bij Debian e.d. moet je zelf multi-arch inschakelen en dan nog is het heel terughoudend met welke 32 bit libraries het installeert. Als je 1 pakket hebt dat 32 bit only is (Skype bijvoorbeeld) dan krijg je alleen die packages die vereist zijn om aan de dependencies te voldoen. Met Aptitude en Synaptic kan je dan nog precies selecteren welke packages het moet gaan updaten in geval er een 32 bit dependency in de weg zit (bijvoorbeeld omdat die er nog niet is).

[swbr]

Je hebt je probleem niet opgelost, je hebt er om heen gewerkt

Die 'protected_multilib' staat niet zonder reden aan by default. Ergens gaat het mis met het installeren van je nss-softokn-freebl package, zo te zien omdat je niet de 'passende' versie van het 32bit package beschikbaar hebt voor de versie van het 64bit package.

Dit hoor je op te lossen door te zorgen dat het 32bit package wel in die juiste versie beschikbaar is. Dit zou geregeld moeten worden door je repo's, maar blijkbaar gaat daar iets mis.

Zo te zien probeer je nss-softokn-freebl-3.14.3-10.el6_5.x86_64 te installeren, het passende 32bit package is snel gevonden met google: http://pkgs.org/centos-6/....3-10.el6_5.i686.rpm.html.

Download dat package en doe 'yum install nss-softokn-freebl-3.14.3-10.el6_5.i686.rpm'. Die zou dan netjes ook het 64bit package als dependency moeten mee installeren.

[ Voor 4% gewijzigd door swbr op 04-06-2014 09:18 ]

[Hero of Time]

Je kan 'm ook van die site downloaden en via "yum localinstall <package>" installeren. Dan worden ook dependencies meegenomen.

[swbr]

Hero of Time schreef op vrijdag 30 mei 2014 @ 19:01:
Je kan 'm ook van die site downloaden en via "yum localinstall <package>" installeren. Dan worden ook dependencies meegenomen.

Dat is precies hetzelfde als ik zeg, yum install <filename> en yum localinstall <filename> zijn al een paar jaar equivalent.

[Hero of Time]

Ja, ok, jouw voorbeeld maakt gebruik van de URL, waar ik een lokaal package gebruik. Ben nog niet zo bekend met Yum. Moet nog steeds Fedora eens installeren op m'n werk laptop, alvast wat meer bekend mee worden voor m'n RHCSA.

[d1ng]

Hero of Time schreef op vrijdag 30 mei 2014 @ 23:39:
Ja, ok, jouw voorbeeld maakt gebruik van de URL, waar ik een lokaal package gebruik.

Het gaat niet om het gebruik van <URL>, maar om <filename> (dus de *.rpm)

[Croga]

Antaresje schreef op vrijdag 30 mei 2014 @ 16:43:
Je hebt je probleem niet opgelost, je hebt er om heen gewerkt

True, very true.

Download dat package en doe 'yum install http://pkgs.org/centos-6/...3.14.3-10.el6_5.i686.rpm'. Die zou dan netjes ook het 64bit package als dependency moeten mee installeren.

Helaas, die server reageert niet. Maar eenzelfde actie via RPMFind leverde een server op die wel reageerde
Bottom line: Geïnstalleerd zonder geklaag van yum en alles werkt dus zal het wel goed zijn

[swbr]

Hero of Time schreef op vrijdag 30 mei 2014 @ 23:39:
Ja, ok, jouw voorbeeld maakt gebruik van de URL, waar ik een lokaal package gebruik. Ben nog niet zo bekend met Yum. Moet nog steeds Fedora eens installeren op m'n werk laptop, alvast wat meer bekend mee worden voor m'n RHCSA.

Oh sorry, ik zie nu pas dat ik een copy/paste fout heb gemaakt. Dat had helemaal geen url moeten zijn achter yum install, maar alleen de filename. Rechtstreeks van een url een package installeren met yum kan niet eens.

[Croga]

Antaresje schreef op woensdag 04 juni 2014 @ 09:20:
Oh sorry, ik zie nu pas dat ik een copy/paste fout heb gemaakt. Dat had helemaal geen url moeten zijn achter yum install, maar alleen de filename. Rechtstreeks van een url een package installeren met yum kan niet eens.

Wat raar... Dat heb ik toch echt gedaan
Weliswaar niet van de URL die gegeven werd omdat die niet meer bestond maar van een soortgelijke URL op RPMFind.

Waarom ook niet? Een url is niets anders dan een pad naar een bestand. Dat dit pad over het internet gaat maakt weinig verschil.

[Hero of Time]

Er is wel degelijk een verschil. Het heeft namelijk een socket nodig om het bestand op te halen. Als dat niet voor die functie beschikbaar is, zal 't niet lukken om 't bestand uit te lezen.