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
