Le 2019-07-08 09:06, Jakub Cajka a écrit :
----- Original Message -----
> From: "Nicolas Mailhot via devel" <devel(a)lists.fedoraproject.org>
> To: "Christophe de Dinechin" <cdupontd(a)redhat.com>, "Development
> discussions related to Fedora"
> <devel(a)lists.fedoraproject.org>
> Cc: "Robin Lee" <nicolas.mailhot(a)laposte.net>, "nicolas
mailhot"
> <nicolas.mailhot(a)laposte.net>
> Sent: Saturday, July 6, 2019 8:39:12 AM
> Subject: Re: New Go Packaging Guidelines landed in rawhide (koji)
> today
>
> Le vendredi 05 juillet 2019 à 16:33 +0200, Christophe de Dinechin a
> écrit :
> >
> > Also, would anybody mind if I add a note on the guideline page
> > stating
> > that this is from F31 on, since the go-rpm-macros package does not
> > exist before. Unless there is a plan to create branches for earlier
> > releases?
>
> It could be done for previous releases, if someone was motivated
> enough. The macro code itself works, with trivial adjustments, on
> ancient releases like EL7. But, it depends on things in redhat-rpm-
> config, so backporting would demand to convince redhat-rpm-config
> maintainers to backport too.
>
> Anyway this is pretty academic right now, I doubt anyone would accept
> a
> backport without synchronized backport of the whole Go packageset, and
> that can not happen before eclipso finishes to update the stack in
> devel.
You have omitted that the new macros stack is not fully backwards
compatible, so it would require more work on fixing the packages that
are affected by the breakage(AFAIK a bit under ~100). IMHO it is not a
good idea to back-port this to any stable Fedora release.
That’s why I wrote that a macro backport, without the mass spec cleanup
& fixing eclipseo is doing in devel right now, would not be a good idea.
(fixing a clean spec to use the new macro stack takes a couple of
minutes; fixing the warts that accumulated in Fedora for years because
the tooling was not there is something else entirely)
--
Nicolas Mailhot