gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Christian Grothoff
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Sat, 2 Feb 2019 16:09:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]