Moin,

folgendes Problem:

ich nutze auf einer dedizierten Kiste, die nur solche Hilfsaufgaben übernimmt, scanbuttond bzw. künftig scanbd mit dem Epson Backend von scanbuttond.

Dummerweise funktioniert scanbuttond respektive das Epson Backend nur mit libusb-compat-0.1.12 - aktuell kommt via pacman aber libusb-compat-0.1.3-2. Scanbuttond wird leider nicht mehr aktiv entwickelt, von daher ist dort keine Besserung zu erwarten, scanbd setzt für die älteren Scanner eben noch auf scanbuttond. Bei jedem Update überschreibt pacman mir die händisch installierte lib mit der aktuellen - im Endeffekt durchaus gewünscht - im speziellen Fall aber eben problematisch.

Da ich erstens nicht nach jedem Update die alte libusb-compat wieder einspielen will noch mir andere Anwendungen, die auf die neuere Version bauen, kaputt machen will, würde ich gerne die ältere Version davon unter einem alternativen Namen installieren - und natürlich scanbuttond bzw. scanbd nur gegen diese alte lib kompilieren.

Zur alten libusb-compat gibt es bereits ein PKGBUILD.

Nun meine Frage - wie stelle ich das am schlauesten an? Oder auch - wonach muss ich suchen (momentan weiß ich nicht wonach ich suchen müsste)?

Ziel ist es, das Ganze irgendwie in Howto-Form zu bringen - und auch da würde ja das Hin- und Her mit der libusb-compat stören.
Du solltest es dir auch einfacher machen können (ich habe mit einer Lib etwas ähnliches):
Umgehe den Paketmanager, aber so geschickt, daß es dieser nicht bemerkt ;-)

Wenn du dir den Inhalt deines alten libusb-compat Paketes anschaust (ich nutze für sowas den mc als Dateimanager), dann siehst du ja den Inhalt, wobei entscheidend für die Laufzeit eigentlich nur die Libs libusb*.so.* sind.
Ich würde nun aus dem alten Paket die beiden Files lib/libusb-$versionsnummern.so.$versionsnummern per Hand nach /usr/lib kopieren. Dabei natürlich aufpassen, daß du keine gleichnamigen Files überschreibst.
So verbietet es sich, ebenfalls den Symlink lib/libusb.so mitzukopieren, da dieser dann ja (als Link) auf die alte so-Version zeigen würde, somit pacman sich beschweren dürfte.

Die Programme sind alle gegen eine bestimmte Version der Libs gelinkt, so sollte dein scanbd eben genau die benötigte /usr/lib/libusb-xyz.so.xyz laden. Du kannst das mit ldd prüfen:
Bevor du deine alte Libs installiert oder hier per Hand kopiert hast (pacman also aktuell ist), sollte
ldd /usr/bin/scanbd (oder wie immer das Binary auch heißt oder abgelegt ist)
für die libusb ein "not found" anzeigen.
nach dem obigen händischen Kopieren sollte ldd anzeigen, daß es diese alte Version nutzt, das Binary also funktionieren sollte.

Alle anderen Files aus dem (alten) Paket solltest du nicht brauchen bzw. werden aktuell für das System über die reguläre libusb-comapt Paket bedient.
Wenn das funktioniert, dann solltest du dir daß, was du kopiert hast irgendwo dokumentieren damit du später nachvollziehen kannst: Warum liegen den diese Files in /usr/lib/, die gehören ja zu keinem Paket...

NB: bei umfangreicheren Paketen ist sowas eher kontraproduktiv bzw. unmöglich, da würde ich es eher auch mit einem PKGBUILD versuchen(wichtig ist halt dabei: keine doppelten Files) und/oder nach /usr/local/lib installieren(was aber oft auch nicht unproblematisch ist). Aber bei Library-Paketen werden i.d.R. wirklich nur die (versionsbestimmten) *.so.* Files gebraucht...
Schreib einfach in deine pacman.conf:

IgnorePkg = libusb-compat

Dann wird libusb-compat bei Updates nicht mehr berücksichtigt.
Bitte nicht..... ;-)
Das Zurückhalten von Libraries ist *KEINE* gute Lösung. Je nach Art der Lib kann dir passieren daß zwar dann ein Tool ggf. noch funktioniert, aber der Rest des Systems nicht.

Ich meine, wir haben es unter Linux doch wirklich recht einfach durch die versionsbezogene Verlinkung von Binaries... Es wirkt zwar auf den ersten Blick blödsinnig, hat aber gegenüber z.B. Windows (soweit ich es noch kenne) mit seiner foobar.dll den Vorteil, daß Libs wirklich in verschiedenen Versionen friedlich nebeneinander leben können. Und nicht wie eben bei Windows bestimmte Versionen einfach mit ins jeweilige Prog-Verzeichnis reingepfriemelt werden...

Die sauberste Lösung wäre halt ein PKGBUILD mit a) anderem Namen und b) keine doppelten Files, also wirklich nur die .so Files. Aber in den Fall hier dürfte es sich lediglich um 2 dateien handeln, die kann man durchaus auch händisch kopieren/verwalten - halt so, daß der Paketmanager nicht durcheinandergerät... My 2 ¢...

//Edit: Und die "allersauberste" Lösung sicher das Neubauen der Programme gegen die aktuelle libusb, aber das fällt ja soweit ich verstanden habe mangels Sourcecode wohl eher flach...
4 Tage später
Nicht ganz - der Sourcecode ist da - kompiliert gegen die neue libusb funktioniert er aber in Teilen nicht - daher meine Idee, die alte "sicher" unter anderem Namen abzulegen. Der Einfachheit halber eben gleich ohne händisches Eingreifen.
So - das Problem ist gelöst - quasi sogar auf zwei Wegen ...

... zum einen hätte mir auffallen können, dass die via PKGBUILD installierte libusb-compat in der Version 0.1.12-1 daherkommt und somit neuer ist als die im core-Repository vorhandene Version 0.1.3-2 - offenbar wird lediglich das Paket dazu nicht mehr gepflegt (siehe https://bugs.archlinux.org/task/23936 ) - ergo wäre die Variante "IgnorePkg = libusb-compat" über die pacman.conf nicht wirklich problematisch gewesen - und natürlich ist der Threadtitel dann auch falsch ...

... zum anderen geht es auch wie folgt (ich wollte jetzt wissen wie es geht 🙂 ) - möglicherweise "von hinten durch die Brust ins Auge" - ich bitte um Kommentare, wenn es einfacher geht - z.B. was man in den Makefiles anpassen / ergänzen muss um nur scanbd gegen die alternative lib zu kompilieren.

Ich bin wie folgt vorgegangen:

1. Kompilieren & installieren der libusb-compat mit dem originalen PKGBUILD (siehe Link oben, ich musste bei mir generell noch 'arm' in die arch Zeile schreiben - aber das ist hier nicht wichtig).


2. Kompilieren, Installieren und Testen von scanbd - mit der Version 0.1.12-1 funktioniert es ja bekanntermaßen.


3. System updaten (yyuu) - Ergebnis (eben die Warnung, die mich hätte stutzig machen können):
[root@hydra] ~/libusb (2,4G free)# pacman -Syyuu
:: Synchronisiere Paketdatenbanken...
 core                                                          37,8 KiB   350K/s 00:00 [##################################################] 100%
 extra                                                        421,9 KiB   777K/s 00:01 [##################################################] 100%
 community                                                    370,9 KiB   657K/s 00:01 [##################################################] 100%
 aur                                                            9,8 KiB  1877K/s 00:00 [##################################################] 100%
:: Starte komplette Systemaktualisierung...
Warnung: libusb-compat: Downgrade von Version 0.1.12-1 zu Version 0.1.3-2
Löse Abhängigkeiten auf...
Suche nach Zwischenkonflikten...

Pakete (1): libusb-compat-0.1.3-2
(...)

4. nochmaliger Test von scanbd - Ergebnis: es funktioniert nicht mehr (mit dem von mir benötigtem epson Backend) - der Scanner wird mit Version 0.1.3-2 nicht mehr erkannt.


5. Kompilieren & installieren der gleichen libusb-compat mit zwei Anpassungen im PKGBUILD ...
# $Id: PKGBUILD 101197 2010-11-28 15:10:38Z tpowa $
# Maintainer: Tobias Powalowski <tpowa@archlinux.org>
# Contributor: arjan <arjan@archlinux.org>

pkgname=libusb-compat-scbd
srcname=libusb
pkgver=0.1.12
pkgrel=1
pkgdesc="Library to enable user space application programs to communicate with USB devices"
arch=('arm' 'i686' 'x86_64')
depends=('sh')
url="http://libusb.sourceforge.net/"
license=('LGPL')
source=(ftp://ftp.slackware.at/slackware-11.0/source/l/libusb/libusb-0.1.12.tar.gz)
options=('!libtool')

md5sums=('caf182cbc7565dac0fd72155919672e6')

build() {
cd ${srcdir}/${srcname}-${pkgver}
./configure --prefix=/usr/local
make
}

package() {
cd ${srcdir}/${srcname}-${pkgver}
make DESTDIR=${pkgdir} install
}
... die bewirken einfach nur, dass zum einen pacman einen eindeutigen Eintrag zu dieser lib in seiner Datenbank hat und zum anderen das die installierten Dateien nicht von der lib aus dem Repository überschrieben werden.


6. erneutes Testen von scanbd - mit einer kleinen Anpassung: 
LD_PRELOAD=/usr/local/lib/libusb.so /usr/local/bin/scanbd -df -c /usr/local/etc/scanbd/scanbd.conf
... und siehe - es klappt.
Das ist ein praktikabler Weg, schließlich wirkt pacman mit den Standard-repos ja auf keinen Fall in /usr/local...

Aufpassen muß man (ebenso wie bei entsprechenden lokal - eben in /usr/local - abgelegten Binaries) nur, daß Suchpfade für BINs und LIBs irgendwann nicht mal das "falsche" finden. Vor allem bei gleichlautenden Namen der installierten Dateien kann das schnell mal passieren. Ist wohl hier speziell wohl nicht das problem (du löst es ja durch explizites Preload), aber als "gedanke im Hinterkopf" sollte man es berücksichtigen...