[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