Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?

[Christian Grothoff]

On 2/10/19 10:57 PM, Hartmut Goebel wrote:
> Am 10.02.19 um 22:28 schrieb Christian Grothoff:
>>> - framework ("core")
>> Should framework include the gnunet-gtk-common, causing GNUnet to drag
>> in Gtk+ (that's a bit along my question of merging gnunet-gtk.git with
>> gnunet.git, which few people seemed to like)?  Should framework include
>> gnunet-postgres and gnunet-mysql and gnunet-sqlite database routines?
>> Does the framework package then always drag in 3 databases as mandatory
>> dependencies?
>>
> While I have no strong opinion about this, I suggest to include the
> db-backends, as optional dependencies. If at least one db-backend is
> required for gnunet to work, at least on should be required to be
> specified using "--with-XXX". If one is building gnunet for his/her own
> use, he/she could select what he/she want. Packager could build all
> backends and carve them out into separate packages (I assume each
> backend to be a few, easy to detect files.)

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?

> 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)?  If for
databases the carving by the packager is acceptable, why not for
cmd-line/Gtk/Qt?

> From a
> packager's POV I'd depend this on how easy the gtk-related files can be
> carved out into a separate package.

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.

> 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.

> -- The following features have been enabled:
> 
>  * Qt5Test (required version >= 5.11.0), Required for building tests
>  * prctl-dumpable, Required for disallowing ptrace on kdesu process
> 
> -- The following OPTIONAL packages have been found:
> 
>  * Qt5Test (required version >= 5.11.0), Required for building tests
>    Required for tests
>  * Qt5Qml (required version >= 5.12.0)
> 
> -- The following REQUIRED packages have been found:
> 
>  * Qt5Gui (required version >= 5.12.0)
>  * Qt5Widgets
>  * Qt5Svg
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>

signature.asc
Description: OpenPGP digital signature