Re: conversation submodule questions

[Christian Grothoff]

Having one gnunet.git makes it MUCH easier to write and maintain the
code today. Working on making things easier for packaging is thus the
wrong move, especially as with TNG and other major open issues in
abundance, the problem is not packaging but fixing/writing the code in
the first place.

So please let's table the bike shed discussion on splitting up the repo
/ making things easier to package until we at least think that the code
itself is somewhere near ready to be actually used.

On 10/26/19 2:19 PM, Schanzenbach, Martin wrote:
> 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.
>>
>

signature.asc
Description: OpenPGP digital signature