On 2/10/19 2:11 PM, [email protected] 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 would probably be ideal to have a list of binary packages,
dependencies (required, suggested) and associated list of files per
package, right?
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:
(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? :-)
signature.asc
Description: OpenPGP digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
