[Top][All Lists]

[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: Sun, 10 Feb 2019 13:56:24 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

On 2/10/19 11:59 AM, Schanzenbach, Martin wrote:
>> --disable-FEATURE flats for configure where then src/ simply
>> doesn't enter certain subdirectories would certainly have my approval here.
> See above, yay more flags. But this is actually a problem I have not thought 
> through tbh. I do not know how GNUnet is supposed to "work" in this regard.
> Example:
> I release reclaim. It is supposed to do X.
> How am I supposed to release this? As a plugin for GNUnet? As _part_ of 
> GNUnet (i.e. I need to tell my users to install this completely unrelated 
> beast which includes a social network and peer-to-peer file sharing)?

I like this way of looking at it, chiefly what is the release plan. It
depends a bit on whether the reclaim components are from a separarate
repository or not. I would follow the general plan we have for GNU Taler:

* The major version (i.e. 0.11 for GNUnet) should indicate API and
  protocol compatibility. So reclaim (or components) would say they
  need GNUnet 0.11.  This would be what you would consider the 'stable'
  basis.  CI tests should run against it, as well as 'master'.
* Other repositories (gnunet-gtk, reclaim components, secushare UIs,
  gnunet-fuse) can then make *independent* point releases, but they
  should be numbered based on the GNUnet major version they require,
  i.e. gnunet-gtk 0.11.1, gnunet-gtk 0.11.2, etc.
* For updates to parts that are part of the GNUnet "core" (say
  API&protocol compatible improvements to transport/cadet/fs), we would
  similarly make gnunet 0.11.{1,2,3}, but this should "guarantee" that
  say gnunet-gtk 0.11.1 works with gnunet (core) 0.11.3.

Which brings up a good point: if for some application (say reclaimID)
the release schedule is completely different (usually: way more
frequent), it might make sense to split it off --- or increase the
'core' release frequency.

Note that I am talking about *source* releases here, as developers
should IMO release *source*, not binaries or VM images.

> I mean, currently I provide an out-of-the-box client with a docker image that 
> runs GNUnet in a configuration that is most sensible for reclaim.

No, that's horrible. The main release should be a source release,
packaging into particular containers, VMs or operating systems should
never be the _primary_ release mechanism. That's almost worse than the
idea of us primarily offering DEBs for download --- and thus effectively
not supporting RPM or Guix. Sure, providing binary packages or images
*in addition* is OK, but IMO not as the primary release mechanism.

> But the architecture of gnunet actually calls more for a GNUnet "app" store 
> for a platform (GNUnet core,transport,gns,cadet et al) with a bunch of apps 
> (fs, social, reclaim).
> Now, ideally I would work with packages in a reclaim installer, i.e.
> - check if gnunet-core is installed, if not install
> - check if gnunet-reclaim is installed, if not install
> - profit.

Well, Guix, RPM and DEB all offer this very easily, you just specify the
dependency. Now, how to build a single gnunet-reclaim package from your
5-6 separate Git repositories and (presumably) source TGZ releases is
beyond me, but I'm not the one who atomized the reclaim sources ;-).

> I mean, what exactly do you expect a package maintainer to do? Have separate 
> packages for fs/social/reclaim? One huge package that depends on everything?

I expect *good* package maintainers to split up our monolith into
separate packages with proper dependencies (which we might document
better for them, but that's another story).  More importantly, there
wouldn't be simply gnunet-core, but more like:

gnunet-core requires gnunet-db
  gnunet-db is provided by
gnunet-fs requires gnunet-core
gnunet-fs-gtk requires gnunet-fs and gnunet-gtk-core
gnunet-reclaim requires gnunet-core
gnunet-secushare might require gnunet-experimental (multicast, psyc) OR
        that might be part of gnunet-core
gnunet-namestore-gtk requires gnunet-gtk-core

Furthermore, I expect that there will be distributions that do not break
it up so much, maybe even to the point of shipping one big monolith
which drags in 1 GB of dependencies. But that's the *distributions*
choice, how many packages they want, what audience they target (our
users have huge disks and do not want 100000+ packages vs. our
distribution targets embedded systems and we try to atomize vs. our
distribution separates resource files that are architecture-independent
into a -noarch dependency) --- there are so many trade-offs here, I
would not even want to be involved in that discussion.

And yes, IMO in extreme cases some distribution might ship every app as
a Docker image (openoffice-docker, gnome-docker, firefox-docker,
emacs-docker, reclaim-docker).  IIRC QubesOS is going in that direction ;-)

> If yes, then how would the build look like? Do they have to "fully" build 
> gnunet 3 times and cherry pick binaries? Do they have separate the build by 
> hand because we build everything or nothing?

It *should* suffice to build "everything" once, and then cherry pick
binaries and/or resource files, simply because we have linked things
_properly_ and use plugins where appropriate, so you can separate
binaries related to sqlite from those related to postgres easily, while
building both at the same time. The same holds for virtually everything
else, including internal dependencies. So yes, distributors should just
turn on everything, build everything once, but then have to cherry pick
binaries by hand. But while we can provide guidance on the cherry
picking, I don't think we can do away with it at the exact grouping
depends on the distro's philosophy.

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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