- Mail original -
De: "Jakub Cajka"
> I think one of the main responsibilities of Fedora packager is to work with
> upstreams, help them
> mature and generally improve their projects.
Sure but expecting everything to be perfect and consistent before shipping
anything just DOES NOT WO
ruary 3, 2018 4:27:36 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
> De: "Jakub Cajka"
>
> Hi Jakub
>
> > I'm strongly against general unrestricted practice of compat packages as
> > proposed.
- Mail original -
De: "Nicolas Mailhot"
> It's a bit of a Lego guideline, you assemble the spec blocs you need, and
> ignore those you don't need. The
> example was chosen to include as many blocks as possible, with the
> walkthrough explaining their respective
> functions. All the blo
De: "Jakub Cajka"
Hi Jakub
> I'm strongly against general unrestricted practice of compat packages as
> proposed. If you need compat package you
> need to work with usptreams on stabilizing the API/project, fork it, or just
> use COPR as your projects(or its
> dependencies) are not yet mature
ruary 1, 2018 4:24:52 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
> De: "Jakub Cajka"
>
> >> Filling upstream holes is pretty much the definition of an
> >> integrator/distributor role. In G
De: "Colin Walters"
> I appreciate the work you're doing here,
Thank you
> but I think the right path for golang (indeed for most other language
> ecosystems) is to autogenerate
> specs.
You're, of course, are entitled to your opinion, but I do not share it :) I
think rpm has been an incred
On Thu, Feb 1, 2018, at 10:24 AM, nicolas.mail...@laposte.net wrote:
>
> Not directly. It does provide the means to easily rev a spec to a new
> code state (version tag or commit), and it makes deps systematic (so
> Fedora tooling can accurately detect what is likely to be impacted by a
> cha
On 02/01/2018 05:49 AM, Jakub Cajka wrote:
On contrary Fedora is trying to fill the hole that upstream Go projects dug them selves in to.
IMNHO Go have traded any subjectively perceived "RPM/deb hell" for even deeper levels of
"Go (vendor) hell".
This unfortunately became a trend: "the old pa
De: "Jakub Cajka"
>> Filling upstream holes is pretty much the definition of an
>> integrator/distributor role. In Go they are particularly numerous and deep,
>> but Fedora users do want their docker and kubernetes (and Kubernetes, BTW,
>> is astonishingly free of the problems that plague many Go
De: "Owen Taylor"
> I'm embarrassed to admit that before I sent my mail I carefully read over
> ... the old PackageDrafts/Go :-( My only excuse is that it was in my
> browser history.
NP, that gave you some context on where Fedora is today.
> Having actually read the relevant parts of "More Go P
ruary 1, 2018 2:51:13 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
> De: "Jakub Cajka"
>
> Hi Jakub,
>
> > It depends (as everything) on available manpower, if you are willing to own
> > your depende
De: "Jakub Cajka"
Hi Jakub,
> It depends (as everything) on available manpower, if you are willing to own
> your dependencies
> you can package anything and everything debundled.
Sure, but available manpower depends on how high the bar you put for people
wanting to join, and right now this b
Hi Nicolas,
I'm embarrassed to admit that before I sent my mail I carefully read over
... the old PackageDrafts/Go :-( My only excuse is that it was in my
browser history.
Having actually read the relevant parts of "More Go Packaging", the
explanation of compat packages and notification procedure
uary 1, 2018 11:21:59 AM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
>
>
> - Mail original -
> De: "Owen Taylor"
>
> Hi Owen,
>
> > Is there a guide for Fedora packagers about how to handle unbu
- Mail original -
De: "Owen Taylor"
Hi Owen,
> Is there a guide for Fedora packagers about how to handle unbundling for
> golang packages? The draft guidelines don't seem to go into any details.
I don't think there is, nor that it is necessarily needed. The posted
guidelines should be
January 31, 2018 6:50:21 PM
> Subject: Re: [Fedora-packaging] Re: Proposed Fedora packaging
> guideline: More Go packaging
>
> Hi Nicolas,
>
> Is there a guide for Fedora packagers about how to handle unbundling for
> golang packages? The draft guidelines don't seem to go into
Hi Nicolas,
Is there a guide for Fedora packagers about how to handle unbundling for
golang packages? The draft guidelines don't seem to go into any details.
I've looked at packaging a few golang packages unbundled, and have
immediately run into:
A) lots of unpackaged dependencies
B) dependenci
>De: "Neal Gompa"
> The only thing I see that might be missing is autogenerating
> bundled(golang()) Provides when a vendor tree exists (with the
> appropriate automatic filters on Requires).
I had though a little about doing it but first, as many Go elements, vendoring
relies on conventions no
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
On Mon, Jan 22, 2018 at 2:45 PM, Neal Gompa wrote:
> On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
> 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 (
20 matches
Mail list logo
