Re: conversation submodule questions

[Schanzenbach, Martin]

Ok I thought about this and I think we had this question before.

The thing is: The default build should actually include _all_ plugins and 
components.
Why? Because else there will never be a package including mysql/postgresql 
conversion/fs etc.

Now the question we had some time ago was:
Should we separate all those subsystems (and probably even plugins) into their 
own respective repositories so that they will also result in individual 
packages; e.g. having:

gnunet.git (main repo. base services: core, peerstore etc maybe even up to GNS, 
this also includes _only_ default plugins, e.g. sqlite/heap backends etc)
gnunet-conversion.git (conv repo)
gnunet-plugins-{mysql,postgres}.git (namestore DB backends for large GNS zone 
admins)
... etc

The other option is to have "fat" default build of gnunet.git where basically 
everything (minus experimental) is built and we force all dependencies. Then, 
any packager will have to build this and after separate the individual binaries 
into smaller packages in order to have sane dependencies (see the conversiation 
stuff but also mysql and postgres)

I kind of like option 1 (again) even though I am now convinced that from a 
developer perspective option 2 is less effort.

Oh and there is an option 3: Like option 2, but the packagers will just put all 
dependencies in the package: mysql, postgres, gstreamer etc etc (<- this is 
what will happen instead of what I wrote in option 2 as that is what we would 
like to see happen)

BR

> On 26. Oct 2019, at 12:59, ng0 <address@hidden> wrote:
> 
> Christian Grothoff transcribed 4.1K bytes:
>> On 10/26/19 12:21 PM, Schanzenbach, Martin wrote:
>>>> On 26. Oct 2019, at 11:12, Christian Grothoff <address@hidden> wrote:
>>>> 
>>>> On 10/26/19 10:16 AM, Schanzenbach, Martin wrote:
>>>>> Really? I am personally responsible for making all of the REST stuff 
>>>>> conditional, i.e. it gets
>>>>> built of you have the depencies, otherwise not. My proposal would be to 
>>>>> change this into:
>>>>> 
>>>>> 1. Not build REST by default
>>>>> 2. Add an --enable-rest switch to build it
>>>>> 3. Make configure fail if dependencies are not met
>>>>> 
>>>>> And do the same to conversation, auction, consensus et al. (maybe even 
>>>>> fs).
>>>>> That way, we can even get rid of --enable-experimental. Which is ill 
>>>>> defined anyway.
>>>>> (Who knows what is build with that switch)
>>>> 
>>>> I doubt that'll get rid of --enable-experimental, as the next thing
>>>> people will ask for is an --enable-all, followed by
>>>> --enable-all-without-experimental. Because experimental was primarily
>>>> for stuff that might not even _build_.
>>>> 
>>>> I personally think it would be better to have --disable-rest and similar
>>>> flags, and by default try to build everything. Otherwise we'll end up
>>>> with people (not reading docs) saying that they wanted to run gnunet-foo
>>>> and couldn't find it (because they forgot --enable-foo). So better fail
>>>> if dependency libfoo is unavailable, and have --disable-foo for those
>>>> who deliberately don't want to build gnunet-foo because they don't want
>>>> it or don't have libfoo.  Plus, I'd keep --enable-experimental, as
>>>> that's for code we really don't think normal users should even play
>>>> around with yet.
>>>> 
>>> 
>>> Yeah seems better for REST and most others, but conversation? Not everybody 
>>> wants to pull
>>> gst/pulse when installing the gnunet package (e.g. headless)
>> 
>> I think it is acceptable for headless installs to use a few configure
>> flags.  Ideally, if a dependency is not found, configure should suggest
>> the right disable flag. I'm thinking of something along these lines:
>> 
>> ERROR: libgst not found, cannot build conversation.
>>  Use --disable-conversation to build without libgst.
>> 
> Yes, I found the total lack of switches for conversation weird.
> See the other email I've sent, I'll work some more switches
> into the configure.ac before the release.
>