Re: graphics/jpeg-turbo vs graphics/jpeg

From: Oliver Fromme <oliver(at)fromme.com>
Date: Tue, 13 Feb 2018 11:13:15 +0100 (CET)

Harold Gutch wrote:
On Mon, Feb 12, 2018 at 09:44:48PM +0100, Heino Tiedemann wrote:
> > es gibt diese beiden kokurrierenden ports, die wohl - wie ich das
> > verstehe - das gleiche leisten:
> >
> > - graphics/jpeg-turbo
> > - graphics/jpeg
> >
> > Ich habe graphics/jpeg installiert.
> >
> > ich frage mich: WER traf dazu WANN die Entscheidung?!

@Heino: Das ist richtig, beide leisten das gleiche.

Es gibt relativ viele Ports, die JPEG-Funktionalität benötigen,
daher wird früher oder später einer der beiden als Dependency
automatisch installiert. Dass in Deinem Fall der zweite
(graphics/jpeg) installiert ist, liegt vermutlich daran, weil
es ihn schon sehr viel länger gibt. graphics/jpeg-turbo gibt
es noch nicht so lange. Aber wie Harold schon schrieb:
Welcher von beiden installiert ist, spielt keine große Rolle,
außer dass der mit „turbo“ im Namen ein wenig performanter ist,
da er bestimmte CPU-Optimierungen verwendet.

Was genau im vorliegenden Fall das Problem ist, kann ich leider
nicht sagen, aber es sieht so aus, als wenn in der Registrierung
der Abhängigkeiten irgendwas kaputt ist. (Sowas habe ich einmal
nach einem manuellen Eingriff in die DB gehabt; ich kann nicht
ausschließen, dass es auch aufgrund eines Bugs passieren kann.)

Ich würde in so einem Fall die betroffenen Pakete komplett
entfernen und neu installieren. Möglichst mit einer „sauberen“
Umgebung, d.h. mit vollständig aktuellem Ports-Tree, leerer
/etc/make.conf und auch ohne Variablen im Environment, die einen
Einfluss nehmen könnten. Möglichst auch bei den Ports-Configs
die jeweiligen Defaults verwenden. Gerade bei Ports mit vielen
Config-Optionen sind nicht alle Kombinationsmöglichkeiten gut
getestet; es ist mir auch schon mehrmals passiert, dass ein
Port mit bestimmten Kombinationen nicht richtig funktioniert
hat, oder sich gar nicht erst bauen ließ.

> [...]
> Im Prinzip kann man sich die umgekehrten Abhängigkeiten eines Ports
> (also eine Liste aller Ports die diesen Port benötigen) auch durch
> "pkg query '%rn' jpeg" anzeigen lassen.

„pkg info -r jpeg“ geht auch. Allerdings ist es in beiden Fällen
nicht rekursiv, d.h. wenn jpeg von einem Paket A benötigt wird,
und dieses wird wiederum von einem Paket B benötigt, dann zeigen
obige Kommandos nur A an, aber nicht B. Dies ist im Gegensatz zum
alten pkg_info Kommando, bei dem die entsprechenden Optionen immer
rekursiv arbeiteten. (Man kann dieses rekursive Verhalten bei
PKGNG mit einem kleinen Skript emulieren.)

> Allerdings funktioniert das
> nicht wenn ein Port jpeg nicht als explizite Abhängigkeit hat sondern
> "USES=jpeg" gesetzt ist. Und letzteres wird vermutlich der Fall sein
> bei was auch immer jpeg nun installieren wollte (bei qpdf z.B. ist das
> so).

Das stimmt so nicht ganz, soviel ich weiß.

Auch bei USES=... werden Dependencies registriert werden, sofern
sie zur Laufzeit benötigt werden, was bei jpeg immer der Fall sein
dürfte. Falls die betreffenden Sachen allerdings nur zum Bauen
benötigt werden (typischer Fall: USES=cmake oder USES=libtool),
dann wird keine Dependency registriert, da das fertige Paket,
nachdem es gebaut wurde, das Tool (z.B. cmake oder libtool) dann
nicht mehr benötigt.

Gruß
   Olli

-- 
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 13 Feb 2018 - 11:13:20 CET

search this site