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

[Schanzenbach, Martin]

So let me get this right:
Example projects that do it "wrong", are in dependency hell and generally 
screwed* include (I urge anyone interested in this thread to at least look at 
the package overview once to get a feeling how they are separated):
https://gitlab.gnome.org/GNOME
https://cgit.kde.org
https://git.xfce.org
https://gitweb.torproject.org

Unless I can actually compare the above (which I am used to and come to except) 
with other similarly sized/active projects it is really difficult to root this 
thread into the real world.
I mean, we are not really arguing that "we" do it right and all of the others 
wrong, are we?
Projects that kind of do it like GNUnet are:
(actually it's not easy finding software collections that fall into this 
pattern)
https://git.kernel.org (although I dislike this comparison because it is a 
product which basically builds into a single file iirc? GNUnet does not build a 
"gnunet" binary. It is a collection of services and CLI tools)
https://hg.mozilla.org/mozilla-central/ (but this actually compares more to 
https://gitlab.gnome.org/GNOME/epiphany than the whole project, same with KDE's 
browser. It is not a collection like GNUnet)
https://github.com/TeX-Live/texlive-source (this one compares nicely, but I 
cannot really find all the components in there I would expect -- ah the irony)

Can anyone give me other examples here? I am genuinely interested.
Looking at this I cannot see how a file-sharing service and CLI tools should be 
in the same repository as a chat service and apps in GNUnet.
It is difficult to find projects that are organised in this way _on a source 
repo level_.
Now, there might be reasons on why separation is _difficult_ at this point for 
GNUnet, but that it not a good explanation on why it is not a good idea to do 
so.
It maybe just shows that separation has started too late and is already tedious 
(see texlive).

*To clarify, _I_ personally think is the way it should be. But am not arguing 
against this so I am playing devils advocate.



> On 11. Feb 2019, at 14:34, Christian Grothoff <address@hidden> wrote:
> 
> On 2/11/19 8:40 AM, Schanzenbach, Martin wrote:
>>> 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 
>> dependencies.
>> 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 has.
>> 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).
>> 
> 
> Ah, sorry, I should have been more precise. When I say "database", there
> are two types of dependencies in may cases:
> 1) The database engine itself, i.e. the "mysql-server" or
> "postgres-server" package
> 2) The library to access the database, i.e. "libmysqlclient" or "libpq"
> 
> In the sqlite3 case, both fall together, but that is uncommon.
> 
> For sqlite3, we have answers from OpenWRT that they do NOT want to
> bundle it as a dependency by default, so they would not want it included
> in the dependencies for gnunet-framework.
> 
> For the others, I agree that the *server* installation is something that
> the user might be expected to manually trigger (as is setting up the DB
> with the access rights).  But installing libgnunetpq (which requires
> libpq) without requiring libpq would violate Debian packaging guidelines
> in a very bad way.  So unless libgnunetnamestore_postgres.so and
> libgnunetpq.so are splitt of into a separate GNUnet package, we would
> require gnunet-framework to introduce hard dependencies on libpq (and
> similarly libmysqlclient). Now, these are not quite as big as the
> database server itself, but still large enough to worry. For example,
> libpq on my Debian system drags in the following dependencies:
> 
> E libssl.so.1.1 => /usr/lib/x86_64-linux-gnu/libssl.so.1.1
> E libcrypto.so.1.1 => /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1      E
> libgssapi_krb5.so.2 => /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so.2  E
> libldap_r-2.4.so.2 => /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2
> O libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> M libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5be3ccf000)
> O libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
> O libkrb5.so.3 => /usr/lib/x86_64-linux-gnu/libkrb5.so.3
> E libk5crypto.so.3 => /usr/lib/x86_64-linux-gnu/libk5crypto.so.3
> E libcom_err.so.2 => /lib/x86_64-linux-gnu/libcom_err.so.2
> E libkrb5support.so.0 => /usr/lib/x86_64-linux-gnu/libkrb5support.so.0
> E liblber-2.4.so.2 => /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2
> ? libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2
> E libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2
> E libgssapi.so.3 => /usr/lib/x86_64-linux-gnu/libgssapi.so.3
> O libgnutls.so.30 => /usr/lib/x86_64-linux-gnu/libgnutls.so.30
> E libkeyutils.so.1 => /lib/x86_64-linux-gnu/libkeyutils.so.1
> E libheimntlm.so.0 => /usr/lib/x86_64-linux-gnu/libheimntlm.so.0
> E libkrb5.so.26 => /usr/lib/x86_64-linux-gnu/libkrb5.so.26
> O libasn1.so.8 => /usr/lib/x86_64-linux-gnu/libasn1.so.8
> E libhcrypto.so.4 => /usr/lib/x86_64-linux-gnu/libhcrypto.so.4
> E libroken.so.18 => /usr/lib/x86_64-linux-gnu/libroken.so.18
> M libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1
> O libp11-kit.so.0 => /usr/lib/x86_64-linux-gnu/libp11-kit.so.0
> M libidn2.so.0 => /usr/lib/x86_64-linux-gnu/libidn2.so.0
> M libunistring.so.2 => /usr/lib/x86_64-linux-gnu/libunistring.so.2
> O libtasn1.so.6 => /usr/lib/x86_64-linux-gnu/libtasn1.so.6
> O libnettle.so.6 => /usr/lib/x86_64-linux-gnu/libnettle.so.6
> O libhogweed.so.4 => /usr/lib/x86_64-linux-gnu/libhogweed.so.4
> O libgmp.so.10 => /usr/lib/x86_64-linux-gnu/libgmp.so.10
> E libwind.so.0 => /usr/lib/x86_64-linux-gnu/libwind.so.0
> E libheimbase.so.1 => /usr/lib/x86_64-linux-gnu/libheimbase.so.1
> E libhx509.so.5 => /usr/lib/x86_64-linux-gnu/libhx509.so.5
> O libsqlite3.so.0 => /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
> E libcrypt.so.1 => /lib/x86_64-linux-gnu/libcrypt.so.1
> E libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6
> M libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
> 
> I've prefixed with "M" those that GNUnet also requires (mandatory), and
> with "O" those that GNUnet might also use (optionally), and with "E"
> those that are exclusively dragged in by libpq. (Note: I did this
> quickly from memory, might be wrong in a detail or other.)
> 
> Regardless, this is still a lot.
>

signature.asc
Description: Message signed with OpenPGP