[Top][All Lists]

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

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

From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Mon, 11 Feb 2019 08:40:33 +0100

> On 10. Feb 2019, at 22:28, Christian Grothoff <address@hidden> wrote:
> Signed PGP part
> On 2/10/19 9:25 PM, Hartmut Goebel wrote:
>> Am 10.02.19 um 17:43 schrieb Christian Grothoff:
>> IMHO gnunet should be split into repos like this:
>> - framework ("core")
> Should framework include the gnunet-gtk-common, causing GNUnet to drag
> in Gtk+ (that's a bit along my question of merging gnunet-gtk.git with
> gnunet.git, which few people seemed to like)?  Should framework include
> gnunet-postgres and gnunet-mysql and gnunet-sqlite database routines?
> Does the framework package then always drag in 3 databases as mandatory
> dependencies?
>> - applications
>>     - file sharing
>>     - conversation
>>     - reclaim
>>     - secushare
>> I would expect every developer working on one of the applications to
>> understand he/she needs to install the framework first. (This is much
>> like KDE is organized.)
>> Using a monorepo for all of this will lead to even more configure-flags,
>> a complex CI setup, ugly merges and complicated bi-secting.
>>> I wrote *good* package maintainers (those that
>>> put in the effort)
>> From a packages perspective: You are wasting my time! I have other
>> things to do but do split up you f*** package!
>> Seriously! When using a huge repo we are shifting the burden onto the
>> packager. If we provide smaller, reasonably sliced repos, this makes
>> packager's live much easier. TeXLive should be a warning for us, same as
>> the gockel's android tools.
> Then please explain how you want to slice the dependencies on the 3
> (possibly more in future, MariaDB says hello) databases and the Gtk+
> logic.  Note that each of these multiplies if one wants to be able to
> ship "minimal" binaries:
> 5 proposed base packages * 3 databases  = 15 packages
> 5 proposed base packages * (gtk/no-gtk) = 10 packages
> =====================================================
> Repositories and TGZ to be created      = 25 packages
> This is not feasible as far as I can tell (and note this is slightly
> simplified, reclaim/conversation do not have a DB yet, but I'm leaving
> out details like different audio backends for conversation, with
> json/without json, gnunet-rest-core, etc. to keep the discussion focused
> on my main point).

No you wouldn't do that. And reclaim does have a DB (only sqlite atm).
What you (usually) have for packagers are build dependencies and runtime 
In the case of DBs it would work like this:

The package is pre-built against all DBs (all plugins are built).
The actual package dependencies only include sqlite (if at all as we often have 
a heap plugin as well). With maybe some "recommended" deps like what apt/deb 
If the user _manually_ edits the default DB plugin in the config, he is 
responsible for installing (and configuring) e.g. mysql.
There is no real way for the packager to do that anyway (as the user might want 
to use a preexisting DB).


Attachment: signature.asc
Description: Message signed with OpenPGP

reply via email to

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