Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again

[Christian Grothoff]

On 11/13/20 12:15 AM, Martin Schanzenbach wrote:
> Hi,
> 
> tl;dr:
> - 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
> developers.

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

Indeed.

> But that would require clear packaging guidelines (from
> US!).

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.

My 2 cents

Christian