calibre und scribus-devel bestehen auf py27-imaging

S

SolarCatcher

Well-Known Member
Hallo,

ich kämpfe einmal wieder mit pkg.

Das Problem: deskutils/calibre und print/scribus-devel bestehen absolut auf graphics/py27-imaging! Kein "pkg set -o" scheint sie davon abbringen zu können und stattdessen py27-pillow zu verwenden. Scribus-devel z.B. sagt:
Code: 
# pkg install scribus-devel
Updating repository catalogue
The following 2 packages will be installed:

	Installing py27-imaging: 1.1.7_3
	Installing scribus-devel: 1.5.0_9
Was dann zu div. Fehlern führt:
Code: 
...
pkg: WARNING: locally installed py27-pillow-2.4.0 conflicts on /usr/local/lib/python2.7/site-packages/PIL/_imagingmath.so with:
	- py27-imaging-1.1.7_3
...

Standardmäßig habe ich folgendes versucht:
Code: 
pkg set -o graphics/py27-imaging:graphics/py27-pillow
und danach
Code: 
pkg install -fR py27-pillow

Weil das nichts brachte, habe ich es auch mit
Code: 
pkg set -o graphics/py-imaging:graphics/py-pillow
sowie Kombinationen aus "py-" und "py27" versucht.

Zu guterletzt habe ich es sogar mit der exakten Version probiert:
Code: 
pkg set -o graphics/py27-imaging-1.1.7_3:graphics/py27-pillow-2.4.0

Der Erfolg blieb aus... calibre und scribus-devel bestehen weiterhin auf py27-imaging.

Weiß jemand, woran es liegt und wie man es mit pkg in den Griff bekommt (in den Ports könnte ich die Abhängigkeiten natürlich händisch anpassen - aber wozu hat man das tolle pkg mit seinen Möglichkeiten)?
 
Ich hol mal aus, vielleicht hilfts weiter.
PIL ist eine Python Bibliothek zur Manipulation von Bilder, hier als py-imaging bekannt. PIL wird seit vielen, vielen Jahren nicht mehr weiterentwickelt und hat div. Mängel uA. kein Python 3 Support. Deshalb wurde PIL geforkt, dieser Fork nennt sich nun pillow. Pillow ist 105%(Bugs wurden behoben) kompatibel zum Vorgänger. Nun bestehen beide Programme auf diese Abhängigkeit. Ich würde den Maintainer mal Bescheid geben, diese Abhängigkeit zu fixen.
 
Ja, pillow ist ja der "friendly fork" von imaging... Soweit ist alles klar. Das aber genau wäre ja der Standarfall für ein "pkg set -o", bei dem ich sage: Alles, was bisher py27-imaging benötigte, soll ab sofort py27-pillow nutzen. In einer Jail hatte das auch tadellos geklappt (da waren es aber nicht scribus bzw. calibre). Daher verstehe ich nicht, warum es hier nicht funktioniert.
 
Hi SolarCatcher,

bei deinem Post hätte ich gerne gelesen welche FreeBSD version du benutzt und ob du deine Pakete evtl selberbaust (poudriere). Man kann sich als Unbeteiligter einfach besser was zusammenreimen.
Dir ist doch bewusst, wenn du ein Paket aus den Ports erstellst zB scribus-devel, dann hat diese fertige Paket eine 'run_dependency' auf graphics/py-imaging. Also scribus-devel.xz wird immer versuchen graphics/py-imaging zu installieren.
!pkg set -o' ändert ja nur die Einträge in deine lokalen Datenbank, damit Ports deren 'Origin' sich geändert hat, angepasst werden ( anstat print/blah wird print/blahblah verwendet) Die zugrundeliegenden Anderungen Im Posrts-Tree, wurden vorher schon gemacht, deshalb gibt es dann einen Eintrag in UPDATING. Somit haben die resultiernden Binärpakete auch die richtigen Abhängigkeiten.
Wie du selbst schon geschriben hast ----> händisch Anpassen löst dein Problem. Alle Ports mit 'py-imaging' Abhängigkeit auf py-pillow ändern und neubauen. Ein 'pkg set -o ...' sollte dann auch funktionieren.
 
Hallo auge,

vielen Dank für Deine Antwort. Ich habe die von Dir gewünschten Zusatzinfos nicht reingeschrieben, weil sie m.E. für die Frage nicht relevant sind. Es macht doch für pkg keinen Unterschied, ob ich 9.3 oder 10.0 verwende... Und Deine Frage nach Paketen oder Ports (Poudrière): Hier dachte ich, dass das selbsterklärend sei - ich frage ja nach einer Lösung mit pkg. Und nicht, wie ich das in den Ports bzw. Poudrière ändern müsste. Also: Ich verwende die Standard-Packages vom FreeBSD-Projekt für den 9er-Zweig. Im Portstree sind die Änderungen auch noch nicht drin: Sowohl calibre als auch scribus-devel setzen nach wie vor py-imaging. Andere Pakete setzen bereits auf py-pillow, so dass es eben zu den Konflikten kommt.

Daher bleibt meine Frage immer noch unbeantwortet: Warum lösen meine Versuche mit "pkg set -o" das beschriebene Problem nicht und wie kann man es lösen, ohne die Ports selbst zu bauen.
 
moin, moin ...

also ich hab mich mal ein bischen schlau gemacht. Im py-pillow Makefile ist ein CONFLICTS_install Eintrag, py-imaging hat keinen. Wenn man das in der richtigen Reihenfolge installieren würde, könnt das evtl klappen.
vorausgesetzt py-imaging und py-pillow sind nicht installiert.
zuerst py-imaging installieren und nur Pakete die dieses benötigt.
dann: # pkg set -o graphics/py-imaging:graphics/py-pillow
jetzt folgt das update von 'imaging' auf 'pillow', ich gehe davon aus, dass 'imaging' bereits gelöscht ist, sobald pkg vor der installlation von 'pillow' prüft ob 'imaging' bereits installiert ist. Die option -R wird ganz bewußt weggelassen.
# pkg install -f graphics/py-pillow
...wenn der 'install' durchläuft' kannst du die Pakete installieren, die 'pillow' benötigen.

Das ganze hat natürlich einen Haken. Jegliche Re-installation eines Paketes das py-imaging "benötigt", wird dieses als Abhängigkeit installieren/intallieren wollen:)
Deshalb auch der 'install' ohne -R
 
@auge
Interessant, was Du da recherchiert hast - aber der Nachsatz ist irgendwie nicht erfreulich... jedes Mal wieder das gleiche Theater... Ich dachte wirklich, dass "pkg set -o" das Problem generell löst... und in der Vergangenheit schien das auch mehrfach so geklappt zu haben. Daher war ich ja so überrascht, als es hier nicht gehen wollte.

@foxit
Wow, klingt spannend, was da mit 1.3 kommt - ich verstehe nur einen Teil Aufzählung, aber wenn es eine bessere Methode zur Konflikt-Beseitigung gibt, soll mir das mehr als recht sein!

Vielen Dank Euch beiden!
 
Jetzt läuft pkg 1.3.2 auf meinem Rechner... aber wenn "pkg set -o" deprecated ist, weiß ich immer noch nicht, wie ich z.B. calibre dazu überreden kann mit py-pillow anstatt mit py-imaging zu arbeiten. Der Versuch ein "pkg install calibre" durchzuführen, führt zu:
Code: 
(...)
New packages to be INSTALLED:
	calibre: 1.45.0
	py27-imaging: 1.1.7_3

The process will require 53 MB more space
21 MB to be downloaded

Proceed with this action [y/N]: y
Fetching calibre-1.45.0.txz: 100% of 21 MB                                    
Fetching py27-imaging-1.1.7_3.txz: 100% of 358 kB                            
Checking integrity... done (1 conflicting)
Checking integrity... done (0 conflicting)
Conflicts with the existing packages have been found.
One more solver iteration is needed to resolve them.
The following 4 packages will be affected (of 1043 checked):

Installed packages to be REMOVED:
	py27-reportlab-3.0_1
	py27-pillow-2.4.0

New packages to be INSTALLED:
	py27-imaging: 1.1.7_3
	calibre: 1.45.0

Ja und nu? Das ist ja genau das Gegenteil von dem, was ich erreichen will - nicht pillow soll ersetzt werden sondern imaging... Leider kann ich aus den Manpages nicht erkennen, was hier zu tun ist (insbesondere ist man pkg-set noch nicht aktualisiert worden - dort hätte ich den Hinweis auf die Alternative zu "pkg set -o" erwartet).
 
Woher soll denn die Konfliktlösung wissen das Pillow identisch mit PIL? Das gleiche Problem müsste doch auch bei Flavours auftreten.
Man müsstes PIL ignorieren können, wenn's zum Konflikt kommt.
 
Hi SolarCatcher,

das binäre Paktet 'calibre' beinhaltet eine Liste von Abhängigkeiten. Darunter auch 'py-imaging'. Immer wenn du versuchst 'calibre' zu installieren, wid diese Liste abgearbeitet.
Du suchst eigentlich eine Lösung, das digital signierte Paket 'calibre...xz' so zu verändern, dass 'pillow' statt 'imaging in der 'LIste' steht.
Da können wir alle nur hoffen, dass das nicht funktioniert:)
 
Hallo darktrym und auge,

bisher gab es genau eine solche Lösung per "pkg set -o"

man pkg-set sagt dazu
Code: 
     -o oldorigin:neworigin, --change-origin oldorigin:neworigin
                Change the port origin of a given dependency from oldorigin to
                neworigin.  This corresponds to the port directory that the
                package originated from.  Typically, this is only needed for
                upgrading a library or package that has MOVED or when the
                default version of a major port dependency changes.  Usually
                this will be explained in /usr/ports/UPDATING.  Also see
                pkg-updating(8) and EXAMPLES.

(...)
EXAMPLES
(...)
      Move the origin libglut to freeglut, and then reinstall everything
     depending on glut to use the new shared library:
           % pkg set -o graphics/libglut:graphics/freeglut
           % pkg install -Rf graphics/freeglut

Schaut Euch dieses Beispiel an. Es ist genau mein Fall. py-pillow (im Beispiel "freeglut") ist die neue Version von py-imaging (im Beispiel "libglut"). Die beiden Beispielzeilen sollten mein Problem lösen - taten es aber unter pkg-1.2.x einfach nicht.

Und nun will ich gerne wissen, wie ich dies mit pkg-1.3.x bewerkstellige, wenn "pkg set -o" lt. Bapt deprecated ist.
 
... ja, das freeglut updatae haben wir ja alle gemacht. Der Punkt ist doch der, dass alle Pakete vorher neugebaut wurden, mir der neuen Abhangigkeit 'freeglut', Jedes binärpaket dass du installierst hat dann auch 'freeglut' in der internen 'Liste'. Du mustest deinem Rechner (lokale Datenbank) jetzt nur noch sagen, welchen port (libglut) er mit wechem (freeglut) zu ersetzen hat.
 
Kleines Update: Ich hatte im Juli dann die beiden Maintainer angemailt und nach einer möglichen Umstellung auf py-pillow gefragt. Vom Calibre Maintainer bekam ich rasch eine dankbare Rückmeldung, der auf py-pillow noch gar nicht aufmerksam geworden war. Seit letzter Woche ist deskutils/calibre nicht mehr von py-imaging abhängig sondern von py-pillow. Und gestern hat auch scribus nachgezogen.

Was mal wieder zeigt, dass es sich echt lohnt, unsere lieben Maintainer/Developers direkt anzusprechen, wenn man ein Problem hat.

Dazu fällt mir noch ein. Vor einigen Monaten hatte ich ein Problem mit einem USB-Audiointerface. Die Firmware wurde über Jahre hinweg sehr schön mit einer uralt-Version von comms/dfu-util geladen. Ein Update auf eine aktuelle Version machte das Zunichte und die alte ließ sich durch andere Änderungen nicht mehr kompilieren. Ich kontaktierte daher die Upstream Entwickler und bekam über mehrere Wochen hinweg einen super Support von Hans Petter Selasky, von dem ich erst später mitbekam, dass er bei FreeBSD am USB-System mitschraubt. Er hat mich Schritt-für-Schritt durch das Debuggen geleitet und für einen zusätzlichen Quirk in libusb gesorgt, der nun alles wieder schön funktionieren lässt. Ich hab mich mit einer kleine "Spende" bedankt, da ich richtig froh war, dass mein altes Audiointerface nun wieder problemlos läuft.

Wir haben schon tolle, nette Leute im FreeBSD-Projekt (und natürlich nicht nur da)!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben