Hi, looks like I overlooked some part of the mail.
Am 10.02.19 um 22:28 schrieb Christian Grothoff: > Then please explain how you want to slice the dependencies on the 3 > (possibly more in future, MariaDB says hello) databases and the Gtk+ > logic. Note that each of these multiplies if one wants to be able to > ship "minimal" binaries: > > 5 proposed base packages * 3 databases = 15 packages > 5 proposed base packages * (gtk/no-gtk) = 10 packages > ===================================================== > Repositories and TGZ to be created = 25 packages Huh? According to https://gnunet.org/configuring-mysql-database the database is configured in gnunet.conf. Thus I assume the database is a plug-in. So why does the number of packages multiply? Is there missing an abstraction layer? Same for gtk, which I assume adds a layer on top of existing tools. Am 10.02.19 um 23:19 schrieb Christian Grothoff: > Excuse me, but wasn't your argument that this was exactly what packagers > would never want to do: carving out part of the code into separate > packages? Why is this acceptable for the DBs, but not for say > FS/conversation? Sorry for not being precise enough. Packager will carve out small pieces and simple stuff. E.g. development-packages, documentation, etc. which can easily be split by selecting some directories or file files clearly to distinguish like libgnunetdbmariadb.so.) But it is a pain in the a** to carve out if files are mazy mixed or split over several directories (lib, include, docs, man, bin, share, etc.). In this special case we were discussing database backends, which I assume consist of a single library (or maybe some more files), which are easy to spot and easy to carve out. Same for the gtk-related files. >> I'm not sure about gnunet-gtk-common. Following the layered approach it >> might be worth keeping it in a repo of it's own. OTOH if gnunet-fs-gtk >> is part of gnunet-fs, it might not make much difference. > Well, but that's the question: do we have a gnunet-fs-gtk.git and a > gnunet-fs.git and a gnuent-gtk-common.git, and building > gnunet-fs-gtk.git requires you to first install the other two (and > before you can do those, you have to do gnunet-framework.git)? As I said. I have no strong opinion regarding gnunet-fs-gtk. But yes, you would need to install gnunet-framework and maybe gnunet-gtk-common first (if we decide to put this into a repo of it's own. I don't see much of a problem beside it's taking a few minutes. A developer should be able to understand this and do it - same for a student. I assume there will not be many people doing this. For me this helps understanding the layers gnunet. Also this helps focusing on the respective part of development. > If for > databases the carving by the packager is acceptable, why not for > cmd-line/Gtk/Qt? See above: this depends on how intermixed the files are. As always in development drawing the line is not black-and-white (contraty to climate change where there is no gray). > I don't see how any carving of particular files is easier or harder. In > all cases, you need to have the list of files and how to carve. Those > instructions we certainly should provide. But once we do that, and if we > accept that some carving by packagers will be required, then I don't see > the advantage of keeping repos separate. As a package I don't want to check if some of these files have changed between releases. I simply don't want to spend my spare-time on this kind of work. >> BTW: The Cmake build system has a nice feature for packagers: It lists >> all enabled and disabled features and optional packages, e.g.: > Sure, that is useful, and our configure(.ac) script already produces > such a list at the end of the output, just before the next-steps > guidance for the user. Well, not really. This list is missing the optional dependencies which are missing. e.g. mysql and postgresql are not listed there. But this summery is no important for our discussion. -- Schönen Gruß Hartmut Goebel Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer Information Security Management, Security Governance, Secure Software Development Goebel Consult, Landshut http://www.goebel-consult.de Blog: https://www.goe-con.de/blog/bin-offiziell-entdecker-einer-sicherheitslucke Kolumne: https://www.goe-con.de/hartmut-goebel/cissp-gefluester/2010-07-passwoerter-lieben-lernen
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
