----- Mail original -----
De: "Neal Gompa"
Hi,
Thanks for the review !
> I really do like this. There are only two issues I have with it:
> 1. This seems to mandate that all packages must be named by their
> import path. My golang package (snapd) is not, intentionally so. I
> don't want to change this.
Well that was not the intent, I probably need to clarify things a bit more. The *devel* package must absolutely be named after the import path (for sanity sake). The core package can be named something else (usually because it's the packaging of an app)
For example in my etcd spec
Name: etcd ← well-known app name
%package -n %{goname}-devel ← go naming for go devel stuff
> 2. Mandating a forge is going to be tricky for self-hosted stuff, or
> people who release Go code as tarballs (it's rare, but it happens).
> How do you deal with that?
The proposal automates integration with forges, it does not mandate it
You can declare manually archivename archiveurl and forgesetup before calling the %gometa macro and
you should benefit from the rest of the automation even on an hosting site it does not know anything about. The whole code tries very hard to let the packager pre-define everything it may guess wrong or not know about to avoid giving up on all the automation just because a little part is wrong.
And even after that you can still declare Source manually and pass arguments to setup the old way it that's what you want
Not calling %gometa at all will kill stuff like goname which is kind of mandatory for consistency.
Regards,
--
Nicolas Mailhot
_______________________________________________
packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
