Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Cc: gol...@lists.fedoraproject.org, "Discussion of RPM packaging standards 
> and practices for Fedora"
> <packag...@lists.fedoraproject.org>
> Sent: Monday, February 5, 2018 3:27:01 PM
> Subject: Re: [Fedora-packaging] Re:  Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Jakub Cajka"
> 
> > Our as Fedora or yours company/org? I believe that your contribution of
> > those in to Fedora will be much
> > appreciated.
> 
> Our was meaning the set of specs we are preparing for inclusion. Can't really
> share them before the macros they depend on are merged in rawhide.
> 
> You can grab most of those from
> https://copr.fedorainfracloud.org/coprs/nim/More_Go_Packaging
> 
> before I nuke it to launch a new build from scratch (if seems a bit of grpc
> bootstraping failed this run so that's back to build log analysis, add
> constrains, scratch, retry, wait 3 days for the result. I s hate the yum
> version in copr, every time there is a dumb decision to make it will make
> it, it manages to make yum in EL7 look smart)

You have to explicit about the specs, TBH I have had more fun with dnf, when it 
fist came out.

I believe that you can already open pull requests and review requests stating 
the dependency(so it doesn't get merger too soon) as it will take it some time 
to merge and details can get ironed out during merging/review. As IMHO your 
guidelines will require whole distro change/rebuild to make it compliant. I 
feel like you haven't been engaging with current maintainers much.

JC

> 
> > But IMHO even your changes will not change this, if you don't have few
> > dedicated packager around to
> > do all the bidding.
> 
> Sure, the changes will only remove some barriers to new Go packagers, they
> can't replace those packagers, or the people who take care of the baseline
> core.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> golang mailing list -- gol...@lists.fedoraproject.org
> To unsubscribe send an email to golang-le...@lists.fedoraproject.org
> 
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Jakub Cajka" 

> Our as Fedora or yours company/org? I believe that your contribution of those 
> in to Fedora will be much
> appreciated.

Our was meaning the set of specs we are preparing for inclusion. Can't really 
share them before the macros they depend on are merged in rawhide.

You can grab most of those from
https://copr.fedorainfracloud.org/coprs/nim/More_Go_Packaging

before I nuke it to launch a new build from scratch (if seems a bit of grpc 
bootstraping failed this run so that's back to build log analysis, add 
constrains, scratch, retry, wait 3 days for the result. I s hate the yum 
version in copr, every time there is a dumb decision to make it will make it, 
it manages to make yum in EL7 look smart) 

> But IMHO even your changes will not change this, if you don't have few 
> dedicated packager around to
> do all the bidding.

Sure, the changes will only remove some barriers to new Go packagers, they 
can't replace those packagers, or the people who take care of the baseline core.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: gol...@lists.fedoraproject.org
> Cc: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>, "Discussion of RPM packaging
> standards and practices for Fedora" <packag...@lists.fedoraproject.org>
> Sent: Monday, February 5, 2018 12:16:14 PM
> Subject: [Fedora-packaging] Re:  Re: Proposed Fedora packaging 
> guideline: More Go packaging
> 
> 
> 
> - 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 WORK. Reality is not black and white, it's messy with
> shades of gray
> 
> Even the C/C++ guys do not manage to ship a compat-free package ecosystem,
> and their projects had a few more decades than Go projects to mature, and
> rpm was pretty much built around C/C++ expectations.
> 
> Compat packages are a fact of life in any large software ecosystem, where you
> can't achieve perfect cohesion. Go is getting *very* large. It needs compat
> packages. That does not mean there will be hundreds of them because,
> creating packages is *work*, that does not need they will need maintaining
> for years, because the aim of each compat package is to get obsoleted as
> fast as possible, but there will always be some of them at any given time.
> We are not building a cathedral. Bazaars are messy when full of life.
> 
> > Do you have any evidence supporting this claim? From my point of view Jan
> > and other packages has
> > been spending lot of time on on boarding packagers and working on tooling.
> 
> No one (and certainly not me) is accusing you or Jan not to spend a crazy
> amount of time and energy trying to make things work. But you did not
> achieve a satisfactory Go state in Fedora, read again what Owen wrote, I
> didn't put any word in his mouth, even though I could have written pretty
> much the same message a few months ago.
> 
> Again, no one (and certainly not me) disputes your level of dedication to the
> "cause". You just made some choices in the past (trying to avoid working
> within rpm via godep, refusing to include different states of the same Go
> code in the distro when major Go apps *disagree* on the correct state to
> include) that didn't work out in practice, with the hindsight of several
> years of Fedora Go packaging and the Go package state achieved in Fedora
> after those years.
> 
> It's time to adjust those choices a bit.
> 
> > From my perspective distribution will end up with crazy amount of
> > bitrotting, backport, constant
> > attention requiring package crud..., IMHO basically same as now, apart of
> > it we will have few 1000s
> > of Go based packages with compat names nobody cares about, instead of
> > current 500 or so packages.
> 
> Fedora has lots of Go packages no one cares about because they do not permit
> building the apps people *do* care about.
> 
> Building the apps people care about requires a more aggressive update policy,
> and accepting people will work in parallel on apps, that demand different
> code states, of common dependencies. And there are not so many of those, I
> count 18 of them in our repo out of 476 Go packages, even though the work is
> not completely finished, and finalizing the build of complex tip apps is
> almost certain to increase the proportion a little. That's awfully *good*
> and *nice* given the "no Go API compatibility" scarecrows people like to
> invoke.
> 
> You won't *ever* attract a large pool of packagers, to work on a package
> baseline, that will eventually in some years permit building apps, but never
> this year, because upstream state is not conflict and compat-free yet.
> 
> Regards,
> 
> --
> Nicolas Mailhot
> ___
> packaging mailing list -- packag...@lists.fedoraproject.org
> To unsubscribe send an email to packaging-le...@lists.fedoraproject.org
> 

Our as Fedora or yours company/org? I believe that your contribution of those 
in to Fedora will be much appreciated.
But IMHO even your changes will not change this, if you don't have few 
dedicated packager around to do all the bidding.

JC
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

De: "Jakub Cajka" 

> Very nice list, it would be nice to have it as sub-wiki page of guidelines. I 
> have took liberty to add
> few points.

Ok, I put it here so people have a place to work on it 
https://fedoraproject.org/wiki/More_Go_packaging#Go_developer_guidance:_making_your_software_third-party-friendly

It can be moved later wherever you feel is more appropriate

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Jakub Cajka]

- Original Message -
> From: "nicolas mailhot" <nicolas.mail...@laposte.net>
> To: "Development discussions related to Fedora" 
> <devel@lists.fedoraproject.org>
> Sent: Tuesday, January 23, 2018 7:45:06 PM
> Subject: Re:  Re: Proposed Fedora packaging guideline: More Go packaging
> 
> 
> 
> - Mail original -
> De: "Mátyás Selmeci"
> 
> Hi,
> 
> > This looks pretty cool!
> 
> Thanks for the feedback!
> 
> > One thing I notice in the limitations section of
> > your draft is a lot of "we can't do XXX due to lack of release
> > discipline..."
> 
> > Do you have any recommendations for Go programmers on how to structure
> > their software so that it is easy to package?
> 
> If there is an interest I can add a section on how to make a Go project
> easier to package, sure.
> 
> It won't be earth-shattering, just the Go declination of basic common sense
> rules that are needed in any coding language, that many Go projects already
> apply (unfortunately not all of them):
> 
> — do not change your import path every other month
> — do not make your code accessible through multiple import paths
> – only use smallcaps in your import path (I know some systems are case
> insensitive. Many others are NOT)
> – communicate clearly the canonical import path of the project at the top of
> your README.md
> — if you absolutely need to change your import path fix your code to use the
> new import path do not rely on http redirections
> – that includes testing and example code
> — do not add a .git suffix to your import path
> 
> — use _testdata for all the material needed by unit test

- make sure that all tests and exclusive test dependencies are really only in 
_test.go files

> – put your example code in _examples (with subdirectories if you ship several
> examples). Do not use creative unusual names such as tutorial.
> – do not pepper your subdirectories with .md files. Keep documentation in the
> project root or in a docs root subdirectory if there is too much of it
> — add a one-line summary and a least a § describing what your project does at
> the top of your README.md
> 
> — choose licenses already vetted by Fedora or Debian
> https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
> – add a licensing file named LICENSE
> — use unmodified plaintext canonical licensing texts, that state the LICENSE
> name at the top of the file
> — if you absolutely want to add an extension to make Windows happy, use
> LICENSE.txt
> — if you absolutely want to name your licensing file something else, please
> do not use something.md
> — do not hide your licensing terms in README.md, do not refer to a license by
> name without providing its text
> 
> – do releases
> — do releases, even for minor fixes. If you haven't felt the need to touch a
> project for months its latest state should be released!
> — do releases, even for projects that can only be called through another
> project. Do not rely on this other project to set code state through
> vendoring (that's easy to do, just propagate the tip project version to the
> ancillary projects at release time, like kubernetes does)
> – use semver for your releases https://semver.org/ Distributors and godep
> will thank you
> – if your project is in git, use a different branch for every major version
> of your project
> — if your project is in git, tag your release x.y.z as x.y.z, or vx.y.z,
> never as vx.y.zprettybeta. Versions and version tags are not the right place
> to document a project maturity.
> — numbers are cheap, never reuse the same number for a pre-release and a
> final release, increase the minor version!
> – please version your import paths with each major release (gopkg.in is good
> for that)

- ideally do major releases in separate branches, so you can do minor 
fixes/releases easily even for older major releases(look at GC) 
- do release whenever you alter your API, extending it, modifying it, removing 
some and document it in the release notes

> 
> – use releases of the projects you depend on
> — never depend on a project that already depends on you (otherwise software
> dependencies stop being a nice directed acyclic graph and you get into
> dependency loop hell. That's a nasic software engineering golden rule, not
> respecting it will bite you sooner or later with or without linux distros,
> despite vendoring)
> – if for some reason, one of the projects you depend on does not release,
> please ask nicely it to do so
> – if for some reason you need a code state in tip which is not in a release,
> please inform the origin you'd like it to do a release, and switch to this
> release as soon as it i

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Mátyás Selmeci" 

Hi,

> This looks pretty cool!

Thanks for the feedback!

> One thing I notice in the limitations section of 
> your draft is a lot of "we can't do XXX due to lack of release 
> discipline..."

> Do you have any recommendations for Go programmers on how to structure 
> their software so that it is easy to package?

If there is an interest I can add a section on how to make a Go project easier 
to package, sure.

It won't be earth-shattering, just the Go declination of basic common sense 
rules that are needed in any coding language, that many Go projects already 
apply (unfortunately not all of them):

— do not change your import path every other month
— do not make your code accessible through multiple import paths
– only use smallcaps in your import path (I know some systems are case 
insensitive. Many others are NOT)
– communicate clearly the canonical import path of the project at the top of 
your README.md
— if you absolutely need to change your import path fix your code to use the 
new import path do not rely on http redirections
– that includes testing and example code
— do not add a .git suffix to your import path

— use _testdata for all the material needed by unit test
– put your example code in _examples (with subdirectories if you ship several 
examples). Do not use creative unusual names such as tutorial.
– do not pepper your subdirectories with .md files. Keep documentation in the 
project root or in a docs root subdirectory if there is too much of it
— add a one-line summary and a least a § describing what your project does at 
the top of your README.md

— choose licenses already vetted by Fedora or Debian 
https://fedoraproject.org/wiki/Licensing:Main?rd=Licensing#Good_Licenses
– add a licensing file named LICENSE
— use unmodified plaintext canonical licensing texts, that state the LICENSE 
name at the top of the file
— if you absolutely want to add an extension to make Windows happy, use 
LICENSE.txt
— if you absolutely want to name your licensing file something else, please do 
not use something.md
— do not hide your licensing terms in README.md, do not refer to a license by 
name without providing its text

– do releases
— do releases, even for minor fixes. If you haven't felt the need to touch a 
project for months its latest state should be released!
— do releases, even for projects that can only be called through another 
project. Do not rely on this other project to set code state through vendoring 
(that's easy to do, just propagate the tip project version to the ancillary 
projects at release time, like kubernetes does)
– use semver for your releases https://semver.org/ Distributors and godep will 
thank you
– if your project is in git, use a different branch for every major version of 
your project
— if your project is in git, tag your release x.y.z as x.y.z, or vx.y.z, never 
as vx.y.zprettybeta. Versions and version tags are not the right place to 
document a project maturity.
— numbers are cheap, never reuse the same number for a pre-release and a final 
release, increase the minor version!
– please version your import paths with each major release (gopkg.in is good 
for that)

– use releases of the projects you depend on
— never depend on a project that already depends on you (otherwise software 
dependencies stop being a nice directed acyclic graph and you get into 
dependency loop hell. That's a nasic software engineering golden rule, not 
respecting it will bite you sooner or later with or without linux distros, 
despite vendoring)
– if for some reason, one of the projects you depend on does not release, 
please ask nicely it to do so
– if for some reason you need a code state in tip which is not in a release, 
please inform the origin you'd like it to do a release, and switch to this 
release as soon as it is available
– never depend on a commit state somewhere between two releases
— document the major versions of the stuff you depend on somewhere easy to 
find. If a major version is only usable past as specific minor version, 
document it
– add a unit test that detects if the project you depend on is missing the part 
that requires being after this minor version

– if your project provides wrappers, connexion glue or anything similar to many 
many many other projects keep the code for each other project in a separate 
subdirectory (Go package) so it can be desactivated without impacting the rest 
of your code if the other project ode has a problem.

— never add changes to the projects you reuse, submit the changes to those 
projects
— if you absolutely need to change a project you reuse, fork it cleanly with a 
new import path so distributors do not accidentally reinject the original 
project
— don't forget to rebase your code on the original project if you don't have 
the energy to maintain your own fork
– rebase to the latest minor version of every project you depend on at release 
time. Do not let changes accumulate 

Re: Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "nicolas mailhot" 
> Now that the non-Go part in redhat-rpm-macros is merged in devel I'll try to 
> do a clean PR on go-srpm-macros. 

> Then once Jan or Jakub accepts it it will be possible to play with the 
> automation in devel and I'll be able to share my specs somewhere (not that 
> the work is finished, but some parts *are* finished and  I'd rather have the 
> people who
> use those packages to review my conversions rather than redo part of them 
> without sharing existing work)

And the PR is done and sent:

https://src.fedoraproject.org/rpms/go-srpm-macros/pull-request/1

Now I only need to revisit
https://fedoraproject.org/wiki/More_Go_packaging

and enhance it with the packaging patterns that emerged after applying the 
proposal to the last few hundreds of Go spec files.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa"


> For snipping, use "[...]" notation to indicate skipped stuff. It's
> hard to tell otherwise.

Ok, that was easy to fix :)

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Neal Gompa]

On Tue, Jan 23, 2018 at 9:40 AM,   wrote:
>
>> - Mail original -
>> De: "Neal Gompa"
>
>>> I'm curious, what are you missing in the preamble ? As far as I can see 
>>> it's all there (even though some values
>>> set to variables %gometa precomputes). I had it's right autogenerated some 
>>> parts of it in the past but it's all
>>> converted to variable use now to avoid packager surprise and permit 
>>> customization.
>
>> Actually, this is fine with me. This is what disturbed me a bit:
>> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples
>
> Ah, yes the examples snip the lines that do not need specific changes for 
> readability
> Is the … not clear enough?
> I fear that putting a full preamble would be even more confusing for some 
> readers. Though if people disagree, I'l try to find some time to add the 
> skipped lines back in
>

For snipping, use "[...]" notation to indicate skipped stuff. It's
hard to tell otherwise.

-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: [Fedora-packaging] Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

> - Mail original -
> De: "Neal Gompa"

>> I'm curious, what are you missing in the preamble ? As far as I can see it's 
>> all there (even though some values
>> set to variables %gometa precomputes). I had it's right autogenerated some 
>> parts of it in the past but it's all
>> converted to variable use now to avoid packager surprise and permit 
>> customization.

> Actually, this is fine with me. This is what disturbed me a bit:
> https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples

Ah, yes the examples snip the lines that do not need specific changes for 
readability
Is the … not clear enough?
I fear that putting a full preamble would be even more confusing for some 
readers. Though if people disagree, I'l try to find some time to add the 
skipped lines back in

-- 
Nicolas Mailhot



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
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

Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Fabio Valentini" 

> So, if I understand correctly, both the forge stuff and the new macros for
> go packaging are completely opt-in?
> If that's correct, this looks like the best solution to me - as old
> packages can then be converted one at a time (which I am looking forward to
> doing for my go packages, btw.).

It is fully opt-in. You can also use some parts and ignore others (though it's 
probably more complex than just using all of it unless you understand the new 
parts really well).

However I should warn that packaging "new-style" something is likely to force 
conversion to "new-style" at least some of its deps."Old-style" manual 
declaration of provides often forgets elements and autodeps have no mercy on 
missing provides. But, some of the "new-style" specs I did depend on existing 
Fedora packages I didn't have to touch.

Now that the non-Go part in redhat-rpm-macros is merged in devel I'll try to do 
a clean PR on go-srpm-macros. 

Then once Jan or Jakub accepts it it will be possible to play with the 
automation in devel and I'll be able to share my specs somewhere (not that the 
work is finished, but some parts *are* finished and  I'd rather have the people 
who use those packages to review my conversions rather than redo part of them 
without sharing existing work)

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Neal Gompa]

On Tue, Jan 23, 2018 at 9:00 AM,   wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>> As long as I can do Obsoletes/Provides for the old name for the devel,
>> unit-test,
>
> BTW is anyone using the unit-test packages? Right now I do not generate them, 
> I don't need them, and making them work with autodeps would be hairy 
> (deploying without autodeps should be trivial however)
>
> To be honest, given all the parts current packages fail to install, I'd 
> expect many of the current unit test packages to fail in mysterious ways, so 
> I'm curious: what use has been found for them?
>

No idea, but I just checked, and I don't even have the unit-test
subpackage enabled on snapd, so I don't particularly care too much
there...



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa" 

> As long as I can do Obsoletes/Provides for the old name for the devel,
> unit-test, 

BTW is anyone using the unit-test packages? Right now I do not generate them, I 
don't need them, and making them work with autodeps would be hairy (deploying 
without autodeps should be trivial however)

To be honest, given all the parts current packages fail to install, I'd expect 
many of the current unit test packages to fail in mysterious ways, so I'm 
curious: what use has been found for them?

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Neal Gompa]

On Tue, Jan 23, 2018 at 8:54 AM,   wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>>  2. if your concern is that the *forge* macros are defective somewhere I'd 
>>> be curious where as you'd be the
>>> first to report an actual technical problem. I've used them intensively in 
>>> rawhide and el7 with many different
>>>rpm tools and they are rock solid for me
>>
>
>> I don't consider them defective. They make me a bit squeamish because
>> I don't see the spec preamble and such because they're autogenerated,
>> but you've mentioned that it's possible to selectively use these
>> things with Go and forge macros.
>
> I'm curious, what are you missing in the preamble ? As far as I can see it's 
> all there (even though some values set to variables %gometa precomputes). I 
> had it's right autogenerated some parts of it in the past but it's all 
> converted to variable use now to avoid packager surprise and permit 
> customization.
>
> For example, what are you missing there?
>
> %<---
> %global goipathgithub.com/hashicorp/consul
> Version:   1.0.2
>
> %gometa
>
> %global common_description %{expand:
> Consul is a tool for service discovery […]}
>
> Name:consul
> Release: 5%{?dist}
> Summary: A tool for easy service discovery, monitoring and configuration
> License: MPLv2.0
> URL: https://www.consul.io/
> Source:  %{gosource}
> %<---
>
> Or here ?
>
> %<---
> %global goipathgithub.com/hashicorp/go-sockaddr
> %global commit 9b4c5fa5b10a683339a270d664474b9f4aee62fc
>
> %gometa
>
> %global common_description %{expand:
> Socket address convenience functions for Go. go-sockaddr is a convenience
> library…}
>
> Name:%{goname}
> Version: 0
> Release: 0.14%{?dist}
> Summary: A Go convenience library to manipulate IP Addresses and UNIX sockets
> License: MPLv2.0
> URL: %{gourl}
> Source:  %{gosource}
> %<---
>

Actually, this is fine with me. This is what disturbed me a bit:
https://fedoraproject.org/wiki/Forge-hosted_projects_packaging_automation#Packaging_examples



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa" 

>>  2. if your concern is that the *forge* macros are defective somewhere I'd 
>> be curious where as you'd be the
>> first to report an actual technical problem. I've used them intensively in 
>> rawhide and el7 with many different
>>rpm tools and they are rock solid for me
>

> I don't consider them defective. They make me a bit squeamish because
> I don't see the spec preamble and such because they're autogenerated,
> but you've mentioned that it's possible to selectively use these
> things with Go and forge macros.

I'm curious, what are you missing in the preamble ? As far as I can see it's 
all there (even though some values set to variables %gometa precomputes). I had 
it's right autogenerated some parts of it in the past but it's all converted to 
variable use now to avoid packager surprise and permit customization.

For example, what are you missing there?

%<---
%global goipathgithub.com/hashicorp/consul
Version:   1.0.2

%gometa

%global common_description %{expand:
Consul is a tool for service discovery […]}

Name:consul
Release: 5%{?dist}
Summary: A tool for easy service discovery, monitoring and configuration
License: MPLv2.0
URL: https://www.consul.io/
Source:  %{gosource}
%<---

Or here ?

%<---
%global goipathgithub.com/hashicorp/go-sockaddr
%global commit 9b4c5fa5b10a683339a270d664474b9f4aee62fc

%gometa

%global common_description %{expand:
Socket address convenience functions for Go. go-sockaddr is a convenience
library…}

Name:%{goname}
Version: 0
Release: 0.14%{?dist}
Summary: A Go convenience library to manipulate IP Addresses and UNIX sockets
License: MPLv2.0
URL: %{gourl}
Source:  %{gosource}
%<---

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: [Fedora-packaging] Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Neal Gompa]

On Tue, Jan 23, 2018 at 5:45 AM,   wrote:
>
>
> - Mail original -
> De: "Neal Gompa"
>
>>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>>
 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.
>
> Hi Neal,
>
> I should probably not let this pass without clarifying:
>
>  1.  if your concern is that the *forge* macros will block packaging of 
> projects not hosted on known forges, they won't:
>   — they include code to disable transparently and without exploding the 
> associated bits if the hosting site is unknown
>   — the packager can pre-define the variables that would have been computed 
> if the site was known and all the rest of the automation will just work
>   — baring that the packager can ignore the site-related computations and use 
> whatever he wants instead in Source: and *setup, which are the only parts 
> that depend on hosting structure knowledge,
>

This was my main concern. There are plenty of people who don't like
any of the known forges. And Go ecosystem incompetence for mandating
URI-style deps and build paths doesn't really stop people from wanting
to do that.

>  2. if your concern is that the *forge* macros are defective somewhere I'd be 
> curious where as you'd be the first to report an actual technical problem. 
> I've used them intensively in rawhide and el7 with many different rpm tools 
> and they are rock solid for me
>

I don't consider them defective. They make me a bit squeamish because
I don't see the spec preamble and such because they're autogenerated,
but you've mentioned that it's possible to selectively use these
things with Go and forge macros.

SUSE does something similar with Python for their "singlespec" part,
and it's fantastic[1][2]. But I'm slightly uncomfortable with the idea
that there's no preamble *at all* in the spec using the Go macros and
it's generated fully by macros.

[1]: https://github.com/openSUSE/python-rpm-macros
[2]: 
https://build.opensuse.org/package/view_file/openSUSE:Factory/python-iniparse/python-iniparse.spec?expand=1

>  3. if your concern is that they won't ever be merged due to some people 
> non-constructive obstruction, well I share it to some point but I won't spend 
> more time arguing unicorns and what-if-maybe 
> I-don't-like-commits-let's-make-them-awful-to-use. The people blocking there 
> are free to take up the maintenance of my ~400 specs and redo them as they 
> want, we'll see how they love to waste tens of minutes per spec to position 
> setup args manually when they have to do it for hundreds of them, every time 
> there is a package update or a forge relayout.
>

Technically, no one has to "accept" anything for the macros to be
available. It's whether the macros would be broadly used. I could, in
fact, tomorrow, make various extra useful macros that I use available
in a package for people to pull in. It doesn't mean anyone has to use
them.

> The main difficulty with the proposal is not the *forge part, it's that 
> automated autodeps are well, automated. As every automation they are strict 
> and unyielding and do not take approximations well. They will fail 
> spectacularly in the following cases:
>
>   1. the packager does not package all the deps of its code → the resulting 
> package is uninstallable because autodeps add requires on missing bits
>
>   2. the packager packages code with garbage imports (very common in example 
> or test code) → the resulting package is uninstallable because autodeps add 
> require
>
>   3. the packager does not own properly the directories where its Go code is 
> installed → given that Go deps depend on directories, Go autodeps also depend 
> on proper directory ownership. Positioning autodeps on Go files themselves 
> would make package build times increase many many times as rpm would try to 
> compute the same autodeps for every single .go file in a directory. (and Go 
> autodeps are already slw as snails because invoking the go command is 
> slow)
>
> All those things are mitigated by the use of %goinstall that filters usual 
> example/test/vendor dirs so they don't trigger autodeps, and tries very hard 
> to own all relevant directories.
>
> For those reasons I don't propose to activate autodeps in old-style golang 
> packages. They need conversion  (and review by a human to check no problem 
> 

Re: Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

De: "Neal Gompa"


>> 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.

Hi Neal,

>I should probably not let this pass without clarifying:
> 3. if your concern is that they won't ever be merged 

And the forge macros are now available since redhat-rpm-config-73-1.fc28 (I had 
missed the push due to upstream renaming the file). Heartfelt thanks to  Jason 
Tibbitts !

I'll focus on pushing the Go parts to go-srpm-macros now so everyone can play 
with them

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[Fabio Valentini]

On Jan 23, 2018 12:41,  wrote:



- Mail original -
De: "Neal Gompa"

>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>
>>> 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.

Hi Neal,

I should probably not let this pass without clarifying:

 1.  if your concern is that the *forge* macros will block packaging of
projects not hosted on known forges, they won't:
  — they include code to disable transparently and without exploding the
associated bits if the hosting site is unknown
  — the packager can pre-define the variables that would have been computed
if the site was known and all the rest of the automation will just work
  — baring that the packager can ignore the site-related computations and
use whatever he wants instead in Source: and *setup, which are the only
parts that depend on hosting structure knowledge,

 2. if your concern is that the *forge* macros are defective somewhere I'd
be curious where as you'd be the first to report an actual technical
problem. I've used them intensively in rawhide and el7 with many different
rpm tools and they are rock solid for me

 3. if your concern is that they won't ever be merged due to some people
non-constructive obstruction, well I share it to some point but I won't
spend more time arguing unicorns and what-if-maybe
I-don't-like-commits-let's-make-them-awful-to-use. The people blocking
there are free to take up the maintenance of my ~400 specs and redo them as
they want, we'll see how they love to waste tens of minutes per spec to
position setup args manually when they have to do it for hundreds of them,
every time there is a package update or a forge relayout.

The main difficulty with the proposal is not the *forge part, it's that
automated autodeps are well, automated. As every automation they are strict
and unyielding and do not take approximations well. They will fail
spectacularly in the following cases:

  1. the packager does not package all the deps of its code → the resulting
package is uninstallable because autodeps add requires on missing bits

  2. the packager packages code with garbage imports (very common in
example or test code) → the resulting package is uninstallable because
autodeps add require

  3. the packager does not own properly the directories where its Go code
is installed → given that Go deps depend on directories, Go autodeps also
depend on proper directory ownership. Positioning autodeps on Go files
themselves would make package build times increase many many times as rpm
would try to compute the same autodeps for every single .go file in a
directory. (and Go autodeps are already slw as snails because invoking
the go command is slow)

All those things are mitigated by the use of %goinstall that filters usual
example/test/vendor dirs so they don't trigger autodeps, and tries very
hard to own all relevant directories.

For those reasons I don't propose to activate autodeps in old-style golang
packages. They need conversion  (and review by a human to check no problem
code is deployed) first.


So, if I understand correctly, both the forge stuff and the new macros for
go packaging are completely opt-in?
If that's correct, this looks like the best solution to me - as old
packages can then be converted one at a time (which I am looking forward to
doing for my go packages, btw.).

Fabio

Regards,

--
Nicolas Mailhot
___
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

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa"

>On Mon, Jan 22, 2018 at 8:33 AM, Dridi Boukelmoune
>
>>> 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.

Hi Neal,

I should probably not let this pass without clarifying:

 1.  if your concern is that the *forge* macros will block packaging of 
projects not hosted on known forges, they won't:
  — they include code to disable transparently and without exploding the 
associated bits if the hosting site is unknown
  — the packager can pre-define the variables that would have been computed if 
the site was known and all the rest of the automation will just work
  — baring that the packager can ignore the site-related computations and use 
whatever he wants instead in Source: and *setup, which are the only parts that 
depend on hosting structure knowledge, 

 2. if your concern is that the *forge* macros are defective somewhere I'd be 
curious where as you'd be the first to report an actual technical problem. I've 
used them intensively in rawhide and el7 with many different rpm tools and they 
are rock solid for me

 3. if your concern is that they won't ever be merged due to some people 
non-constructive obstruction, well I share it to some point but I won't spend 
more time arguing unicorns and what-if-maybe 
I-don't-like-commits-let's-make-them-awful-to-use. The people blocking there 
are free to take up the maintenance of my ~400 specs and redo them as they 
want, we'll see how they love to waste tens of minutes per spec to position 
setup args manually when they have to do it for hundreds of them, every time 
there is a package update or a forge relayout.

The main difficulty with the proposal is not the *forge part, it's that 
automated autodeps are well, automated. As every automation they are strict and 
unyielding and do not take approximations well. They will fail spectacularly in 
the following cases:

  1. the packager does not package all the deps of its code → the resulting 
package is uninstallable because autodeps add requires on missing bits

  2. the packager packages code with garbage imports (very common in example or 
test code) → the resulting package is uninstallable because autodeps add require

  3. the packager does not own properly the directories where its Go code is 
installed → given that Go deps depend on directories, Go autodeps also depend 
on proper directory ownership. Positioning autodeps on Go files themselves 
would make package build times increase many many times as rpm would try to 
compute the same autodeps for every single .go file in a directory. (and Go 
autodeps are already slw as snails because invoking the go command is slow)

All those things are mitigated by the use of %goinstall that filters usual 
example/test/vendor dirs so they don't trigger autodeps, and tries very hard to 
own all relevant directories.

For those reasons I don't propose to activate autodeps in old-style golang 
packages. They need conversion  (and review by a human to check no problem code 
is deployed) first.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Re: Proposed Fedora packaging guideline: More Go packaging

[nicolas . mailhot]

- Mail original -
De: "Neal Gompa" 

Hi,

Thanks for the review !

> 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.

Well that was not the intent, I probably need to clarify things a bit more. The 
*devel* package must absolutely be named after the import path (for sanity 
sake). The core package can be named something else (usually because it's the 
packaging of an app)

For example in my etcd spec

Name:etcd ← well-known app name
%package   -n %{goname}-devel ← go naming for go devel stuff

> 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?

The proposal automates integration with forges, it does not mandate it

You can declare manually archivename archiveurl and forgesetup before calling 
the %gometa macro and 
you should benefit from the rest of the automation even on an hosting site it 
does not know anything about. The whole code tries very hard to let the 
packager pre-define everything it may guess wrong or not know about to avoid 
giving up on all the automation just because a little part is wrong.

And even after that you can still declare Source manually and pass arguments to 
setup the old way it that's what you want

Not calling %gometa at all will kill stuff like goname which is kind of 
mandatory for consistency.

Regards,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org