Le samedi 11 janvier 2014 à 13:51 -0800, John Ralls a écrit : > That said, what I proposed was to fork libdbi or SOCI *into gnucash*. It > would become part of the GnuCash source code and would cause you no more > trouble than the other bits of GnuCash lifted from other projects like LibQOF > or the register (lifted largely from Gnumeric). It might cause *us* some > trouble maintaining the code, and your comment is very helpful to that aspect > of the discussion. Thanks.
Thanks for your reply. I had actually understood that you meant a fork inside gnucash. Whether you maintain it within the same source tree or in a separate source tree is not really relevant in this case. The problem is rather the duplicate codebase: from the point of view of the distribution (Debian) as a whole, it really means that there would be two copies of libdbi in it, and it is bad for the same reasons that you don't want two almost identical copies of a file in a single project (you rather want to factorize the common parts, which is the purpose achieved by a library at the distribution level). For example, that means that if a security issue were discovered in libdbi, then our security team would have to analyse and possibly fix two packages instead of one, hence double workload. The fact that GnuCash already has embedded copies of libqof and the gnumeric register is not a good reason to add more embedded copies :) -- .''`. Sébastien Villemot : :' : Debian Developer `. `' http://www.dynare.org/sebastien `- GPG Key: 4096R/381A7594
signature.asc
Description: This is a digitally signed message part
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
