----- Mail original -----
De: "Jakub Cajka"
Hi Jakub,
> For my part I doubt I'll ever use it in EL6 since I did it
> for Go and the EL6 Go stack is really too old for a merge to be interesting.
> Anyway I'll certainly let you know when I feel the time is right (but do not
> block on me!)
If we are talking about EPEL6 stack, it is fairly fresh(1.9.2) and
stable(it will be on 1.9 for whole of its
upstream support), although Go packaging macros are missing.
Yes the core golang package is there but first the other Go macros are not available in
EL6 and second the software level of many common Go packages is very old in EL6.
So, assuming the forge macros just work in EL6, because the little bit of rpm lua they
need works the same as in EL7 and devel, updating EL6 to the level needed for a Go spec to
be shared mostly unchanged between EL6/EL7 and devel would require:
— making the other Go macros available in EL6 (and I'm far from sure they would work
unchanged in EL6, the forge part is easy since it's 100% lua but the other parts
exercise the shell and rpm and other stuff that may behave in a slightly different way in
such an ancient codebase. Not necessarily a show-stopper but definitely something that
requires testing and adjusting time by someone)
— updating all the common Go software packages to the same level as in devel. I don't
say it can't be done (after all I'm doing it for EL7 on hundreds of packages) but
that's a *lot* more work than just updating a few macro files. Especially if it hits
bootstraping issues not existing in EL7 and devel.
Therefore, it requires someone with time and motivation, and should really not be
attempted before EL7 and devel are done and things have settled a bit, and by that point
will there still be enough interest in upgrading the Go state in EL6 for it to be worth
the pain?
Of course one could limit oneself to making the macros available (which still requires
some testing and eventually some code porting), that would enable using the same Go spec
coding style in EL6 EL7 and devel, if not sharing the spec themselves, but the interest of
autodeps is severely limited, if you do not have a large baseline of packages providing
the deps (and the dep version) other packages need to build.
That's why I wrote the forge part could be made available in EL6, it depends on little
except the lua built in rpm, and can be useful as-is, while the Go part is something else
entirely, as its utility is directly linked to the quantity and freshness of Go software
packages in the distro.
Regards,
--
Nicolas Mailhot