[Top][All Lists]

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

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

From: Hartmut Goebel
Subject: Re: [GNUnet-developers] Proposal: Make GNUnet Great Again?
Date: Mon, 11 Feb 2019 17:01:58 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0


looks like I overlooked some part of the mail.

Am 10.02.19 um 22:28 schrieb Christian Grothoff:
> 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

Huh? According to the
database is configured in gnunet.conf. Thus I assume the database is a
plug-in. So why does the number of packages multiply? Is there missing
an abstraction layer? Same for gtk, which I assume adds a layer on top
of existing tools.

Am 10.02.19 um 23:19 schrieb Christian Grothoff:
> Excuse me, but wasn't your argument that this was exactly what packagers
> would never want to do: carving out part of the code into separate
> packages? Why is this acceptable for the DBs, but not for say
> FS/conversation?

Sorry for not being precise enough. Packager will carve out small pieces
and simple stuff. E.g. development-packages, documentation, etc. which
can easily be split by selecting some directories or file files clearly
to distinguish like But it is a pain in the a**
to carve out if files are mazy mixed or split over several directories
(lib, include, docs, man, bin, share, etc.).

In this special case we were discussing database backends, which I
assume consist of a single library (or maybe some more files), which are
easy to spot and easy to carve out. Same for the gtk-related files.

>> I'm not sure about gnunet-gtk-common. Following the layered approach it
>> might be worth keeping it in a repo of it's own. OTOH if gnunet-fs-gtk
>> is part of gnunet-fs, it might not make much difference. 
> Well, but that's the question: do we have a gnunet-fs-gtk.git and a
> gnunet-fs.git and a gnuent-gtk-common.git, and building
> gnunet-fs-gtk.git requires you to first install the other two (and
> before you can do those, you have to do gnunet-framework.git)? 

As I said. I have no strong opinion regarding gnunet-fs-gtk. But yes,
you would need to install gnunet-framework and maybe gnunet-gtk-common
first (if we decide to put this into a repo of it's own. I don't see
much of a problem beside it's taking a few minutes. A developer should
be able to understand this and do it - same for a student. I assume
there will not be many people doing this.

For me this helps understanding the layers gnunet. Also this helps
focusing on the respective part of development.

> If for
> databases the carving by the packager is acceptable, why not for
> cmd-line/Gtk/Qt?

See above: this depends on how intermixed the files are. As always in
development drawing the line is not black-and-white (contraty to climate
change where there is no gray).

> I don't see how any carving of particular files is easier or harder. In
> all cases, you need to have the list of files and how to carve. Those
> instructions we certainly should provide. But once we do that, and if we
> accept that some carving by packagers will be required, then I don't see
> the advantage of keeping repos separate.

As a package I don't want to check if some of these files have changed
between releases. I simply don't want to spend my spare-time on this
kind of work.

>> BTW: The Cmake build system has a nice feature for packagers: It lists
>> all enabled and disabled features and optional packages, e.g.:
> Sure, that is useful, and our configure(.ac) script already produces
> such a list at the end of the output, just before the next-steps
> guidance for the user.

Well, not really. This list is missing the optional dependencies which
are missing. e.g. mysql and postgresql are not listed there. But this
summery is no important for our discussion.

Schönen Gruß
Hartmut Goebel
Dipl.-Informatiker (univ), CISSP, CSSLP, ISO 27001 Lead Implementer
Information Security Management, Security Governance, Secure Software

Goebel Consult, Landshut


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

reply via email to

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