I propose we just add a couple of configure switches, you know --build-deb (if course one for each deb-based distro), --build-rpm etc... you know, to "reduce" complexity. Of course, in addition to the --disable-gtk/--disable-<subsystem> switches which all default to "false" and also build optionally only if the dependencies are actually met. </irony>
> On 10. Feb 2019, at 16:53, [email protected] wrote: > > Signed PGP part > Christian Grothoff transcribed 4.7K bytes: >> 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'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 >> [email protected] >> https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
