----- Original Message ----- > From: "Marcin Dulak" <marcin.dulak@xxxxxxxxx> > To: "Discussion of RPM packaging standards and practices for Fedora" <packaging@xxxxxxxxxxxxxxxxxxxxxxx> > Cc: golang@xxxxxxxxxxxxxxxxxxxxxxx, "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx> > 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 < 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 > 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 -- packaging@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx > > > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx
