gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] packaging GNUnet for OpenWrt


From: Christian Grothoff
Subject: Re: [GNUnet-developers] packaging GNUnet for OpenWrt
Date: Mon, 01 Jun 2015 08:58:30 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0

On 06/01/2015 08:07 AM, carlo von lynX wrote:
> Sorry for the break of thread, the HTML view doesn't show the
> Message-Id for me to refer to.
> 
> I was thinking of writing up an ebuild recipe for gentoo, that would
> have a whole lot in common with Daniel's excellent openwrt Makefile.
> To avoid further duplication I can imagine it would be practical if
> the gnunet build process was capable of making smaller installs by
> selection via configure flags. It already has many switches like
> --enable-experimental and --without-microhttpd but probably could
> offer more to fit the new installation use cases... like, why did it
> produce gnunet-scrypt, gnunet*template, gnunet-daemon-regexprofiler,
> gnunet-helper-transport-wlan-dummy, gnunet-service-dht-* for average
> desktop users even?

Because some like gnunet-scrypt, and the wlan-dummy is required for
running 'make check' (and it must be in the normal installation
directory for 'make check' to work).

Some of the others (regexprofiler, templates) we could consider
noinst-ing.  The main issue is that if you do that to a 'template', the
user of the template needs to do one more thing to make it actually work
properly (beyond copy&paste).  But, maybe that's not a good enough reason.

> Man, why haven't I been on this mailing since about 2002?

That I cannot answer.

> On the topic of guix using gnunet's file sharing (which is something
> I always wanted from distros) I was wondering if psyc's pubsub could 
> be useful for pushing things instead of pulling them, but I guess 
> that depends on pubsub actually being available.

I agree, and we mentioned this. However, for now it does make sense for
Guix to build on what exists and works.  Given that they just use
command-line tools anyway, it'll probably be relatively easy to switch
to a better/alternative scheme in the future.

Attachment: 0xE29FC3CC.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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