On 2/2/19 12:51 PM, Schanzenbach, Martin wrote: > One other thing to this comment: > This dependency hell is a result of the bad/horrible architectural design > choice. It should have been avoided in the first place.
Eh, which one specifically? That comment is way too broad to be actionable. > And yes, a separation of gnunet-<service> and gnunet-<service>-gtk is > perfectly reasonable. Again, source-level or DEB-level? > As I said, the build order does not matter. For anyone building from source, it does. So if we decide how to package source, we MUST consider this. > If we want to offer a "gnunet-util-gtk" package, so be it. Again, source or DEB? > The shared gtk implementations of subsystems is questionable anyway unless > the "main" gtk UI allows some kind of > plugin mechanism for services and does not hardcode them. I think you are not up-to-date on gnunet-gtk: 1) the "main" gtk UI *used to* have a plugin mechanism, but moreover 2) the main gtk UI has been removed as nobody really liked it So gnunet-gtk is right now just a TGZ with gnunet-conversation-gtk, gnunet-fs-gtk, etc. but no "gnunet-gtk" binary is created. And I wonder if it wouldn't make sense to have the gnunet.git configure.ac test for Gtk+ and *if* libgtk is detected, _then_ build Gtk GUIs that are _included_ in gnunet.git, instead of requiring the user to download and configure yet another TGZ. As for DEBs, I do agree that each of the GTK GUIs should probably be a separate package.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
