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 16:51:57 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0

Martin, I'm not sure (1) that all of these really compare to GNUnet, and
(2) if I look at say Tor, the "tor.git" is 350 kLOC as _one_ component.
gnunet.git is 500kLOC, so just a _bit_ larger. Like Tor, we also have
many semi-related repos, you can think of ooni == Taler, ascension
==bridgedb, etc. The _core_ Tor system are not the 50 repos you find
they have. All a _normal_ user needs is tor.git, which is _completely_
self-contained and already usable.

Looking at another example, I checked out kdelibs, which is arguably the
equivalent of the 'framework' for GNUnet.  After all, the question is at
what size one really needs to break things up more, right?  kdelibs has
1399 kLOC (yep, that's just the basic library). So in what respect do
these projects where the most fundamental base logic is 3x as big as
what we have really _compare_?

The main argument -- build/CI/test time, internal complexity, all falls
apart given that they are (overall) at least an order of magnitude
larger, and their basic components dwarf our core libraries at this time.

On 2/11/19 4:34 PM, Schanzenbach, Martin wrote:
> 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.
>>
> 

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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