Re: [GNUnet-developers] On applications using GNUnet

[Schanzenbach, Martin]

Hi,

thanks for the changes. It is a very large pull request, too big to merge in 
one swoop.
However, there are some things that might be useful. Others we should talk 
about:

0. Is there a reason you include the new header into every single C file? There 
does not seem to be
a need for that in most cases.

1. If you want to build an application, even if it is "just" a CLI you need to 
decide if
you want to add it to the GNUnet tree or build it externally. As you said you 
tried to
build it externally first, but the PREFIX/lib location situation on gentoo 
makes this difficult?
If yes, we should try to address this problem first.
You can specify the libdir and libexec using configure, e.g.:

./configure --libexecdir=/usr/lib64 --libdir=/usr/lib64

2. When 1. is fixed, the change/addition you made to getopt makes sense and we 
should try to
slim a patch/changeset down to just that.

3. If you still want to build your application in the tree, then the changes to 
the gnunet
help output in 1. and 2. are not necessary (as it will be GNUnet after all).
Unless you choose to for in which case just replace/hardcode your
 contact details. It would not make sense to report bugs of your fork to GNUnet 
anyway.

I guess first we need to decide if you want to go with 1+2 or 3.
Hope this helps?

BR
Martin

> On 5. Aug 2019, at 13:53, Alessio Vanni <address@hidden> wrote:
> 
> Hi Martin,
> 
>> Are you building your app in a separate source tree (gnunet-ext) or inside 
>> gnunet?
>> If it is the latter, then this is the expected behaviour.
>> If it is the former, then this might also be an issue that could be addressed
>> in gnunet-ext => bugreport.
> 
> At first I used gnunet-ext, but then I started writing everything from
> scratch, from configure.ac to the client/service's source code.  It
> actually ended up being very similar to gnunet-ext, but it was a nice
> learning experience (the differences were mostly in the directory tree
> structure and "meta" files like Makefile.am.)
> 
>> You could get an account and push it as a branch.
>> Alternatively, maybe fork https://gitlab.com/gnunet/gnunet and push your 
>> changes
>> in your gitlab account. Eventually we/you can merge it. But at least we can 
>> all look at
>> it first then ;)
>> 
>> This is a great example for how our onboarding and collaboration is, well,
>> at this time not-existant. At least not in the way git{hub,lab} allows you
>> to contribute.
> 
> The plan was to submit it for review and change anything if needed.
> I'll try submitting a pull request on Gitlab in a few minutes.  I
> haven't had the chance to use Gitlab for this kind of thing yet, so I
> need to understand how it works first.  I'll also try to include a
> summary of the work done.
> 
>> Yes, your service must be installed under $GNUNET_PREFIX/gnunet/libexec in 
>> order for
>> ARM to find it. If your service is a GNUnet service, it is reasonable to
>> enforce/expect this also for 3rd party services. Does this limit you in
>> any way?
> 
> On Gentoo (which I use as my main Linux distribution) until some months
> ago, /lib and /usr/lib were symlinks to /lib64 and /usr/lib64.
> Nowadays, instead, those became real directories containing 32bit
> libraries (e.g. since I occasionally have to use wine, I have some files
> there.)  Because of this change, I can't install my GNUnet service in
> /usr/lib anymore but have to explicitly use /usr/lib64.  If I hardcode
> it, however, it is not guaranteed that I can always safely install in
> /usr/lib64 on every other distribution: it is always possible for a
> distribution to do the opposite, i.e. change /usr/lib to /usr/lib32 and
> /usr/lib64 to /usr/lib, for example.  There aren't any that do this as
> far as I know, but it can be done.  It wouldn't really be an issue if I
> always pass the '--with-gnunet' argument to configure, but I also expect
> configure to automagically find the GNUnet installation, especially if
> it's in a "standard" place (maybe thanks to a package manager) without
> having to explicitly pass it as an argument.  I can't think of an easy
> way to do it within configure.ac and, as far as I could see, it seems
> GNUnet doesn't explictly export GNUNET_PREFIX (as a variable or even
> something else.)
> 
>> Basically GNS is a "petname" system. Which means that you decide on
>> your names in your local root zone (e.g. TLDs). Similar to how you choose
>> names for your contacts in your phone.
>> In your example, you would most likely find a QR code on that flyer which 
>> you tell you
>> a public key.
>> I guess the most practical way would be to take a photo of the flyer first.
>> At home, you would scan the QR code using your PC and retrieve the public 
>> key.
>> You can store this public key under any TLD you wish, could
>> be "fun" or "flyer" or anything really. There are no global names in GNS as
>> there is no global registry such as ICANN (or a consensus like in 
>> blockchains).
>> (The gnunet-qr tool is there to help with this import)
>> When you have imported that key, you can resolve the website as "party.fun" 
>> OR "party.flyer" etc.
>> 
>> Now, GNS actually does feature globally unique naming as well but only if you
>> use public key hashes as the TLD.
>> For example, if the QR code on the flyer encodes a public key "P", then the 
>> name
>> party.<hash(P)> is a valid name and globally resolvable for anybody.
>> Unfortunately, it is hard to remember that for humans so only really 
>> feasible/useful for
>> applications that require unique names.
> 
> I see.  I'll explore gnunet-qr then, and maybe come back if there are
> still some obscure parts.
> 
>> BR
>> Martin
> 
> Thank you.
> 
> A.V.
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: Message signed with OpenPGP