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

[Schanzenbach, Martin]

I propose we just add a couple of configure switches, you know --build-deb (if 
course one for each deb-based distro), --build-rpm etc... you know, to "reduce" 
complexity.
Of course, in addition to the --disable-gtk/--disable-<subsystem> switches 
which all default to "false" and also build optionally only if the dependencies 
are actually met.
</irony>

> On 10. Feb 2019, at 16:53, address@hidden wrote:
> 
> Signed PGP part
> Christian Grothoff transcribed 4.7K bytes:
>> On 2/10/19 2:11 PM, address@hidden wrote:
>>> *We* have define what it should look like. *We* have to set the
>>> expected results. *We* have to say, this is how gnunet should
>>> look like. Every deriviation from what we say in the official
>>> installation methods is without warranty. Every good packaging
>>> system in an OS closely follows downstream (= us).
>>> We have to provide choice or document a way to build a recommended
>>> gnunet release. Never expect distributors to handle this properly
>>> on their own. It took way to long to split up TexLive, and that's
>>> still being done inofficial with everyone following a different
>>> pattern.
>> 
>> I agree that we should make a sound proposal for packaging, but I am
>> simply not under the illusion that packagers would follow it.
> 
> It's as simple as that: we set the rules. Good systems follow it,
> irresponsible systems keep doing whatever. It's really just that
> 2 colored, from my experience.
> Even when they are not "rules", words like 'we recommend to build
> gnunet like ...' will be taken as the official way to build it.
> And if there will be 2 ways to do it, one has to be labeled the
> prefered way. Just as I told you about idn2 support and checking
> for it the way we do.
> 
>> It would probably be ideal to have a list of binary packages,
>> dependencies (required, suggested) and associated list of files per
>> package, right?
> 
> yes, similar to PLIST and the buildlink3 framework (in pkgsrc).
> 
>> Having such a list in our documentation would make a _lot_ of sense to
>> me.  Note that for this, some minimal tooling to sanity-check the list
>> would be good. Here I'm thinking of (1) checking with ldd whether a
>> binary/library in package X has all dependencies satisfied either within
>> the package or its required dependencies, plus (2) a GNUnet-specific
>> check that if I link against 'libgnunetFOO' and there is a "FOO"
>> service, that the gnunet-service-FOO and a 'config.d/foo.conf' is in the
>> package or its required dependencies.
>> 
>> To do that, we'd probably want some formal format for the packaging
>> proposal. Guile would seem a, eh, natural candidate? ;-).  I'm thinking
>> of something like this:
> 
> Guile isn't really strong favored, you get two or 3 big projects
> with it now, but if you want to do this I'd really prefer a
> language which is alive outside of a tight-knit circle.
> Whatever it's written in has to be maintainable by us and
> future contributors. Just my opinion.
> The idea itself sounds good
> 
>> (spec
>>  (package ("gnunet-fs-gtk"
>>    (dependencies ( ("gnunet-fs" #t) ("gnunet-gtk-core" #t) )
>>    (files ("bin/gnunet-fs-gtk"
>>            "share/gnunet-gtk/gnunet-fs-gtk.glade") )
>>  )
>> )
>> 
>> Anyone here who'd like to script a spec validator? :-)
>> 
> 
> 
> 
> 
>> _______________________________________________
>> GNUnet-developers mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP