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

[ng0]

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: PGP signature