gnunet-developers
[Top][All Lists]
Advanced

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

Re: Open questions regarding new messenger and secushare and organizatio


From: Martin Schanzenbach
Subject: Re: Open questions regarding new messenger and secushare and organization Was: Make GNUnet Great Again
Date: Fri, 13 Nov 2020 22:17:53 +0900
User-agent: Evolution 3.38.1 (3.38.1-1.fc33)

Thank you all for your feedback.
I think I am leaning towards keeping it mostly as is and organizing
possible candiates for exclusion around their dependencies.

Let me make my packaging concerns a bit more precise.
What we probably do NOT want to happen is a single gnunet package wich
depends on

- sqlite, mariadb and postgres (DB backends)
- bluetooth (transport plugin)
- gtk
- gstreamer (conversation)

Because for obvious reasons this is not a good idea. E.g. a user may
run a headless system.
Components which do not have excessive dependencies could always be
included in a core package due to how ARM functions.

Now, we could recommend packaging as follows:

- gnunet (pulls in all mandatory runtime dependencies)
- gnunet-db-plugin-$DBP (Where $DBP is mariadb/postgres)
- gnunet-transport-plugin-$TP (Where $TP is bluetooth atm)
- gnunet-gtk (already exists)
- gnunet-conversation
(- gnunet-qr)

For example: The alpine package currently simply does not provide
conversation or mariadb/postgres DB plugins, which is a good idea as it
would mean dependency bloat.

It is a lot easier to do this from dedicated repositories.
Or we need some kind of "packaging" guidelines where it is recommended
that gnunet is built with all optional dependencies and then the
respective binaries are put into specific packages.
A first step would be to distinguish between "build dependencies" such
as texlive and/awk/automake/gcc/etc and "runtime depdendencies".
Then, we could basically allow a packager to decide to package a single
package with optional dependencies or multiple packages for each
component requiring one or more optional dependencies. However, our
current README does not make this clear at all. It is targeted towards
developers building from git.

I will open an issue for this in mantis as we should address this in
one way or the other.

BR

On Fri, 2020-11-13 at 12:36 +0100, Christian Grothoff wrote:
> 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
> 

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

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