[gnucash-de] gnucash-hbci paket fXr debian sarge

Christian Stimming stimming at tuhh.de
Mon Apr 4 07:59:18 EDT 2005


Hi,

Thomas Viehmann schrieb:
>>Heißt das Paket libaqhbci2? Wenn ja, warum die "2"? 
> 
> Bei Debian werden die So-Versionen der Bibliotheken stets im Paketnamen
> mitgeführt, damit mehrere ABI-inkompatible Versionen gleichzeitig installiert
> werden können (libchipcard2 heißt auch libchipcard2-0). (Das wird z.B.
> interessant, wenn GnuCash gegen eine andere So-Version von AqBanking gelinkt
> ist als QBankManager). 

Ach so, klar, dann ist alles ok. Ich war nur überrascht.

> Deshalb mache ich ja auch immer so einen Streß wegen
> Kollisionen von Dateinamen. Andere Distributionen werden das in gewissen
> Grenzen machen, die dezentrale Entwicklung von Debian macht es notwendig,
> dieses Vorgehen zum Prinzip zu erheben.

Klar, sag weiterhin Bescheid. Wir möchten ja auch den Debian-Regeln 
gerne so gut es geht entgegen kommen. Nur kenne und benutze ich nun mal 
kein Debian, und deshalb setzen wir uns halt erst nach der Rückmeldung 
in Bewegung.

Von daher auch die Sache mit den (deiner Meinung nach) vielfachen 
Verlinkungen:  Schick uns gerne Vorschläge/patches, wie das anders 
laufen sollte.

>>?!? Was sollen denn die Entwickler sagen? 
> 
> Wollt ihr in 2 Jahren noch etwas von AqHBCI 1.0.x beta und AqBanking 1.0.7
> hören? In Debian/stable werden dann nur noch (und hoffentlich genau und noch
> besser sehr selten) Sicherheitsprobleme und Bugs der Preisklasse "schickt mein
> Geld ans falsche Konto" behoben. Leider habe ich als Debian-Maintainer ein
> größeres Paket mit einem Release Candidate in stable geerbt, seitdem scheue
> ich mich Versionen mit dem Beta-Etikett hochzuladen.

Ich als Programmierer tu mich da leider sehr schwer, irgendwelche zur 
Debian-stable-policy passenden Statements zu geben. Denn ich spüre 
wesentlich deutlicher die Forderungen der Anwender, daß neue Features 
vorhanden sein mögen (hier v.a. HBCI-Pin/Tan), und die kann ich nun mal 
nicht in zwei-Jahres-Rythmen planen. Ich kriege hier nur direkt die 
"Beschwerden" von Anwendern, die an ihre Bank rankommen wollen, und 
versuche dann, kurzfristig darauf zu reagieren. Mein Ziel, kurzfristig 
den Anwender-Wünschen hinterherzukommen, kollidiert an dieser Stelle 
wohl leider direkt mit den Debian-Zielen, die du hier (korrekterweise) 
vertrittst. Natürlich will ich in zwei Jahren nichts mehr von 
aqhbci-1.0.x wissen, aber ich will auch in einem Jahr nichts mehr von 
openhbci-0.9.17 mehr hören.

In dieser Hinsicht erscheint es mir da eher "unglücklich", daß 
gnucash-1.8.10 ohne die HBCI-Features überhaupt nach Debian hochgeladen 
wurde. Denn daß die Anwender dann aus allen Wolken fallen, wenn ihre 
HBCI-Konten plötzlich nicht mehr erreichbar sind, ist ja eigentlich 
absehbar und auch berechtigt. Da hätte ich eher erwartet, daß 
gnucash-1.8.10 eben solange warten muß, bis aqbanking auch in Debian 
vorhanden ist. Diese Update-Entscheidung hätte aus meiner Sicht nicht 
voneinander getrennt werden sollen.

> Eine andere, ganz praktische Frage ist: Zählt Ihr bei ABI-inkompatiblen
> Änderungen auch schon bei AqBanking die So-Version hoch? Ich komme drauf, weil
> beii Version 0 nicht unüblich ist, die Abi für nicht stabil zu halten.

Ja, bei ABI-inkompatiblen Änderung wird die so-Version hochgezählt. Seit 
den ersten tarbal-releases gab es aber *nur* Hinzufügungen, keine 
Änderungen/removes, und deswegen ist SO_MAJOR gemeinsam mit SO_AGE immer 
hochgezählt worden, so daß die effektive so-version bisher auf Null 
stehen geblieben ist. Wir könnten die mal erhöhen, aber das wäre dann 
mehr um der Optik willen und weniger auf Grund einer ABI-Inkompatiblität.

Re libosp: Ich hab da nichts von libosp irgendwo drin, allerdings hab 
ich das ofx-plugin innerhalb des aqbanking-Pakets auch abgeschaltet. Wir 
haben relativ viele libraries (z.B. libdl, libssl, libcrypto), die nur 
aufgrund des "-lgwenhywfar" beim Erstellen von z.B. libaqbanking mit 
reinkommen. Hast du Vorschläge, wie man das loswird? Nehme ich gerne 
entgegen.

Gruß

Christian