[Top][All Lists]

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

Re: Open questions regarding new messenger and secushare and organizatio

From: Nikita Gillmann
Subject: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again
Date: Fri, 13 Nov 2020 13:00:03 +0100
User-agent: Mozilla/5.0 (X11; NetBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.3.2

On 11/13/20 12:36 PM, Christian Grothoff wrote:
On 11/13/20 12:15 AM, Martin Schanzenbach wrote:

- Should we move towards a monolithic gnunet.git repo which includes
gtk/secushare again?
gtk+: I'm still undecided ;-).

Secushare: it's been unmaintained for a while, and unless someone else
steps up to actually get it working and properly maintain the code
through API changes, I am not really willing to put in the effort to
keep tons of code compiling that so far adds zero value.

- Should we instead move optional components (conversation, reclaim,
messenger) out of gnunet.git as extensions?
Those are maintained and don't add huge dependencies. So here I see no
need to move them out. Given that gnunet-arm launches services
on-demand, there is absolutely no harm in having a few small extra
binaries installed even if a user doesn't actively use them.

- Is "messenger" a part of "secushare"?
That's a political question for those who claim to speak for "secushare"

Long version:

I was wondering how "messenger" relates to "secushare".
Some time ago we moved secushare and related components out of
gnunet.git and into an extension repository [1].
In my view, it's a fresh attempt to build something that might be
considered part of / become part of the secushare vision. That said, I
think its premature given that messenger clearly is still evolving, and
secushare remains largely vaporware
(Secushare-people: do correct me if I am wrong here).

Now, I do not think we have settled on an approach on how to handle our
component structure. Some time ago I proposed to move most components
out of gnunet.git into extension repos while grothoff argued that maybe
we should even include gnunet-gtk in the main repo [2].
It is unclear in general when to use gnunet-ext and when to develop a
component in-tree.
gnunet-ext was mostly intended for new experimental components
(especially student projects) ;-).

I would like to take this opportunity to restart this discussion:
Should we move secushare back into gnunet.git? (Is the secushare team
even planning to maintain it?)
That's the key point: if someone maintains it, it can come back.

Is messenger an alternative to secushare or should it be part of it?
Should we move towards a more monolithic repo in general and merge
secushare/gtk as well?

I still have concerns with respect to packaging from a monolithic
repository structure. A distribution may want to offer multiple gnunet
packages for each component (reclaim, secushare, gtk) in oder to more
efficiently handle dependencies.
It's worse. A distribution may want to split even the GNUnet core git
repo into say libraries and actually running the peer. GNU Taler depends
on various GNUnet libraries and gnunet-arm/gnunet-config, but a GNU
Taler exchange operator most likely will not want to actually launch a
GNUnet peer and might not want to even deploy CADET or GNS
binaries -- and certainly not our SUID helpers.

So depending on the distro policy/purpose, the single-source may need to
be split up into a multi-package anyway.

But this may be discouraged if we have a single repo as packaging
becomes more tedious.
Think monolithic texlive vs modular texlive packages (I think most
distributions now have a modular package).
OTOH, releasing tarballs for each component is also a pain for us as
Not to mention a pain for us to check that everything still builds
(gnunet-gtk often FTBFS because someone updates gnunet.git and fails to
realize that this broke gnunet-gtk.git or gnunet-fuse.git). And for
users that don't use a package manager, downloading, configuring and
building dozens of TGZ is even worse.

We probably also should not too much conflate repository structure and
packaging structure.
A monolithic repository structure could still result in modular

But that would require clear packaging guidelines (from
We did start writing some years ago. Packagers never looked at them AFAIK.

Also, source distributions (gentoo et al) always require the
(full) source tree checkout even for a small component.
A modular repository structure would make it a lot easier for
distribution packaging in any case.

I think I proposed a separation into a set of "core" gnunet service and
extensions. But I am not so sure anymore if that is a good idea. For
example, missing DHT block plugins of extensions in the "core" package
would result in bad performance of the extension service (?).
I strongly think that splitting it up more is a bad idea. We may indeed
want to merge at least gnunet-fuse.git, and if maintained
gnunet-secushare.git, and possibly even gnunet-gtk.
We should allow independent building then, as a packager I'd hate to see the already big dependency chain grow by gtk. Arguably we already have enough dependencies accumulated that the "small" gtk doesn't add that much weight to it. Regardless of this I'm in favor if we integrate them to allow building only these parts or not build them at all.

My 2 cents


reply via email to

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