----- Original Message -----
> From: "Marcin Dulak" <marcin.du...@gmail.com>
> To: "Discussion of RPM packaging standards and practices for Fedora"
> <packag...@lists.fedoraproject.org>
> Cc: gol...@lists.fedoraproject.org, "Development discussions related to
> Fedora" <devel@lists.fedoraproject.org>
> Sent: Monday, January 22, 2018 4:04:19 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging guideline: More
> Go packaging
>
>
>
> 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
>
Hopefully something like this will never happen as generally I'm strongly
against shipping multiple versions(of one implementation) of Go concurrently.
JC
>
> 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
>
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
