On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa <ngompa13@gmail.com> wrote:
On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
<dridi.boukelmoune@gmail.com> wrote:
>> 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.
>> 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?
> By not using the macros for packages not fitting the model?

The issue is that the new Go macros are tightly wound into the forge
macros. I just want to be sure that we can leverage things like the
dependency generators without all the other stuff.

> I think this is very helpful especially when it's the common practice,
> and I certainly won't blame anyone doing proper releases and not
> just a git tag with github releases notes ;)
> Regarding naming, I think python packages must be prefixed with
> python[23]- and can Provides: the upstream project name.

I'm not sure if this matters in this discussion but an example Python3 part of a spec file https://fedoraproject.org/wiki/Packaging:Python
to accommodate also EPEL (which on CentOS7 prefixes Python3 packages with python34 and not python3) would look like:

%package -n python%{python3_pkgversion}-%{pname}
%{?python_provide:%python_provide python%{python3_pkgversion}-%{pname}}

On the
> other hand we have packages like docker that are clearly named
> after upstream's name, so I don't think that would be a problem for
> snapd. (and maybe an exception needs to be granted?)

This rule only applies to Python packages that have modules that are
designed to be imported by other Python code. Otherwise, this is not

真実はいつも一つ!/ Always, there's only one truth!
packaging mailing list -- packaging@lists.fedoraproject.org
To unsubscribe send an email to packaging-leave@lists.fedoraproject.org