On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
<dridi.boukelmoune@xxxxxxxxx> 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}}
Macin
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
necessary.
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
packaging mailing list -- packaging@lists.fedoraproject.org
To unsubscribe send an email to packaging-leave@lists.fedoraproject.org
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
