----- 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 _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
