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 <[email protected]> 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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
