Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?

[Christian Grothoff]

On 2/10/19 4:41 PM, Schanzenbach, Martin wrote:
>> 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.
> Wat. No, you are completely missing the point I am making. I am
> saying that I cannot conceivably provide adequate installation
> instructions for _one_ service that is built on GNUnet.
> 
> Hence, for our PoC (reclaim client), I took the easy route (for the
> user): A docker image pre-built with what is needed. I fully agree
> that this way of doing it is completely incompatible with other
> GNUnet installations and is not the way it should be done. But
> currently, if I want users to try it out, it is the _only_ reasonable
> way. The reason why it is the only reasonable way is the bloatiness
> and complexity and missing packages for gnunet that provide a minimum
> viable system.

Ok, I can see this as a viable short-term approach, but I thought we
were discussing what the long-term plan is here, right?

>>> 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-mysql gnunet-sqlite gnunet-postgres 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 ...
> 
> Hahah you expect package maintainers to do that from what results
> from a "make" in gnunet.git? Are we living on the same planet?

Yes (with adequate documentation provided by us). But please do read my
e-mails more carefully: I wrote *good* package maintainers (those that
put in the effort) would end up with something like the above. I do not
expect this to be common.

>> 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 ;-)
> No. I do not think any maintainer would agree. You do not give the
> maintainer this monster and say "there you go, have fun breaking it
> down if you need to". You provide proper, functionally separated
> units to package. Ideally source separated for automated builds. (see
> ng0's comments)

As I said, I am not under the illusion that all maintainers would break
it up the way we would like, even if we provide good documentation on
how it should be broken up.  But, that does not make a compelling
argument for me for breaking up our source into the same units we want
to see in the binary packages. Because that would mean 50+ TGZ files
today, and more in the future.

>>> 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.
> 
> See above. This is "F** Magic", not "Actual Machine" thinking;
> https://fritzfreiheit.com/wiki/AM/FM
> There are only two ways this ends:
> 
> 1. gentoo-like source-based distros: provide installation-time flags
> (for which gnunet is actually ok to install then) 2. DEB-like distros
> that will provide "gnunet" packages that pull: Gtk+ (if we include it
> in gnunet.git), postgres, mysql, sqlite, libgabe, ... (you get it)
> 
> The reason why (2) will happen is because people don't have time for
> this shit. Some goes for 1, btw. It is just coincidentally a good
> approach.

I will not maintain a separate Git repository and configure.ac and TGZ
and CI setup for every freaking libgnunetdatastore_postgres.so plugin,
just because it should be a separate binary package so that Postgres is
not dragged in with the rest.  That's also AM thinking for me as
maintainer.

As for reality (2), that is _fine_. If for the sake of expediency and
ease of packaging we end up with GNUnet installs of 5 GB for some
distros, I don't care. As I said before, the distros will decide how
much effort they put into breaking it up, how much it is worth to them
to make this fine-grained. If someone doesn't have the 5 GB, they can
follow our instructions to break it up. If they don't have the time to
do this, buy bigger disks. The possibility of world (2) is hardly a good
reason for us maintaining and releasing 500 TGZ files and asking users
who want to build from source to download those that they need.

signature.asc
Description: OpenPGP digital signature