gnunet-developers
[Top][All Lists]
Advanced

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

Re: Packaging problems


From: Willow Liquorice
Subject: Re: Packaging problems
Date: Thu, 2 Jun 2022 16:29:51 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.1

Right. Perhaps the onus is on the developers (i.e. us) to make things a bit easier, then?

To be honest, I barely understand how the GNUnet project is put together on a source code level, let alone how packaging is done. One of the things I'm going to do with the Sphinx docs is provide a high-level overview of how the main repo is structured.

On the subject of complexity, I attempted to disentangle that awful internal dependency graph a while ago, to get a better idea of how GNUnet works. I noticed that it's possible to divide the subsystems up into closely-related groups:
        * a "backbone" (CADET, DHT, CORE, and friends),
        * a VPN suite,
        * a GNS suite,
        * and a set operations suite (SET, SETI, SETU).

A bunch of smaller "application layer" things (psyc+social+secushare, conversation, fs, secretsharing+consensus+voting) then rest on top of one or more of those suites.

I seem to recall that breaking up the main repo has been discussed before, and I think it got nowhere because no agreement was reached on where the breaks should be made. My position is that those "applications" (which, IIRC, are in various states of "barely maintained") should be moved to their own repos, and the main repo be broken up into those four software suites.

As Maxime says, GNUnet takes a long time to compile (when it actually does - I'm having problems with that right now), and presumably quite a while to test too. The obvious way to reduce those times is to simply *reduce the amount of code being compiled and tested*. Breaking up the big repo would achieve that quite nicely.

More specifically related to packaging, would it be a good idea to look into CD (Continuous Delivery) to complement our current CI setup? It could make things easier on package maintainers. Looks like Debian has a CI system we might be able to make use of, and all we'd need to do is point out the test suite in the package that goes to the Debian archive.




reply via email to

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