Re: [gnucash-de] Re: aktuelle gnucash-hbci/aqbanking für Sarge?

Christian Stimming stimming at tuhh.de
Die Okt 25 10:44:00 EDT 2005


Hallo Micha,

Micha Lenk schrieb:
>>Warum ist dann in Debian
>>libaqhbci noch ein separates Paket? Im upstream ist seit aqbanking>=
>>1.3.0 das libaqhbci im aqbanking-Paket enthalten, 
>>http://linuxwiki.de/AqBanking#upgrade
> 
> Ein Grund ist, dass AqHBCI -- auch wenn der AqBanking-Quellcode AqHBCI
> enthält -- eine eigene Bibliothek ist und als solche in ein eigenes
> Paket gehört.

*röchtöchtöchthüstelhüstel* Ich fänd's gut, wenn wir uns darauf einigen, 
dass es immer noch die aqbanking-Maintainer sind, die entscheiden, was 
ins aqbanking-Paket "gehört". ;-)

Die Entscheidung der Integration von allem ins aqbanking-Paket geschah 
genau deswegen, weil diese interne Auftrennung zwar den technischen 
Gegebenheiten entsprach, aber nicht die Sichtweise des Users 
widerspiegelt. Das Kriterium "eigene Bibliothek" zieht hier erstmal gar 
nicht, weil ein Programm oder ein Bibliothekspaket aus jeder Menge 
unterschiedlichen "libxyz.so" bestehen kann. Aber aus Sichtweise des 
Users wird nur der ganze aqbanking-Krempel auf einmal benutzt. Also ist 
er nun auch alles auf einmal im Paket drin. Fertig, aus -- zumindest aus 
unserer Sicht.

> Wenn ich das richtig verstanden habe, sind ja die verschiedenen Backends
> auch als Plugins zu verstehen, d.h. wenn man die richtigen Binärdateien
> der Backends weglässt, kann AqBanking halt kein OFX oder keine
> Geldkarten mehr. Diese Plugin-Architektur versuchen wir bei der
> Paketierung von AqBanking zu erhalten. 

Wir empfehlen diese Vorgehensweise *nicht*. Das bildet zwar die interne 
Technologie nach, aber die interessiert doch eh kein Mensch. Es geht 
darum, den Usern eine Funktionalität anzubieten, und das geschieht nun 
mal erst durch die Kombination der ganzen Elemente. Deshalb empfehlen 
wir jeder distro implizit, die Paketaufteilung entsprechend unserer 
Entscheidung nachzubilden, also die aqhbci-Sachen in einem als aqbanking 
bezeichneten Paket gleich drinzulassen. In einer Aufteilung nach 
requirements würde es ggf. noch lohnen, ofx und geldkarte separat zu 
haben, aber das ist dann eben eine potentielle Vereinfachung zur 
Trennung der requirements.

> Wie oben gesagt: Wir bauen lieber mehrere Pakete (aus einem Quellcode)
> und setzen die Abhängigkeiten entsprechend. Wenn man das richtig macht
> sollte das keine Nachteile sondern nur Vorteile haben.

Dann bleiben die Debian-Fragen eben alle bei euch erstmal hängen. Kann 
ich halt nix dran ändern. Aber glücklicherweise bist du hier ja auch 
sehr aktiv und kooperativ, so dass das sicher auch weiterhin 
funktionieren wird (besten Dank fürs häufige Posten).

Gruß

Christian