On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa <ngomp...@gmail.com> wrote:
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune > <dridi.boukelmo...@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}} 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 -- packag...@lists.fedoraproject.org > To unsubscribe send an email to packaging-le...@lists.fedoraproject.org >
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
