Schanzenbach, Martin transcribed 5.2K bytes:
> 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.
Before I read a concrete proposal in code I will just say No to the part
above.
I have seen downstream software maintainers trying to do this, and really
we shouldn't (pybitmessage had a good fallout phase with this).
It's the packagers job, not ours. more work, we can't provide
the same quality, yada yada.
> 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, n...@n0.is wrote:
> >
> > Signed PGP part
> > Christian Grothoff transcribed 4.7K bytes:
> >> On 2/10/19 2:11 PM, n...@n0.is 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
> >> GNUnet-developers@gnu.org
> >> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>
> _______________________________________________
> GNUnet-developers mailing list
> GNUnet-developers@gnu.org
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
_______________________________________________
GNUnet-developers mailing list
GNUnet-developers@gnu.org
https://lists.gnu.org/mailman/listinfo/gnunet-developers
