gnunet-developers
[Top][All Lists]
Advanced

[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: Mon, 11 Feb 2019 14:34:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

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.

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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