Translating Go modules buildrequires in rpm syntax

[Nicolas Mailhot]

Hi,

For Go modules, that will become the default upstream in August, Google
invented holed BuildRequires version ranges:
– anything starting with version
– except a list of specific version exclusions (not exclusion ranges,
specific versions)

Basically upstreams are allowed to declare incompatible versions, but
Google would really like them to keep ascendent API compatibility
(and Google requires module renaming on major version changes, so there
is no upper limit to the API compatibility)

Is the correct way to represent those in rpm:

BuildRequires: ((golang-module(github.com/stretchr/testify) >= 1.3.0) and
((golang-module(github.com/stretchr/testify) < 1.3.2~0.20180906233101.161cd47e91fd) or
(golang-module(github.com/stretchr/testify) > 1.3.2~0.20180906233101.161cd47e91fd)) and
((golang-module(github.com/stretchr/testify) < 1.3.2~1.pre1) or
(golang-module(github.com/stretchr/testify) > 1.3.2~1.pre1)) and
((golang-module(github.com/stretchr/testify) <
1.3.2~1.pre1.0.20180628173108.788fd7840127) or (golang-module(github.com/stretchr/testify)
> 1.3.2~1.pre1.0.20180628173108.788fd7840127)))

or am I missing something obvious?

Best regards,

-- 
Nicolas Mailhot

[Nicolas Mailhot]

Le vendredi 29 mars 2019 à 20:33 +0100, Nicolas Mailhot a écrit :
>  
>  Is the correct way to represent those in rpm:
>  
>  BuildRequires: ((golang-module(github.com/stretchr/testify) >= 1.3.0)
>  and ((golang-module(github.com/stretchr/testify) <
>  1.3.2~0.20180906233101.161cd47e91fd) or (golang-
>  module(github.com/stretchr/testify) >
>  1.3.2~0.20180906233101.161cd47e91fd)) and ((golang-
>  module(github.com/stretchr/testify) < 1.3.2~1.pre1) or (golang-
>  module(github.com/stretchr/testify) > 1.3.2~1.pre1)) and ((golang-
>  module(github.com/stretchr/testify) <
>  1.3.2~1.pre1.0.20180628173108.788fd7840127) or (golang-
>  module(github.com/stretchr/testify) >
>  1.3.2~1.pre1.0.20180628173108.788fd7840127)))
>  
>  or am I missing something obvious? 
The usual suspects on #fedora-devl (thank you very much) pointed me to


((golang-module(github.com/stretchr/testify) >= 1.3.0) without
((golang-module(github.com/stretchr/testify) = 1.3.2~0.20180906233101.161cd47e91fd) or
(golang-module(github.com/stretchr/testify) = 1.3.2~1.pre1) or
(golang-module(github.com/stretchr/testify) = 1.3.2~1.pre1.20180628173108.788fd7840127)))

Which is a lot more palatable

-- 
Nicolas Mailhot

[Tom Hughes]

On 29/03/2019 19:33, Nicolas Mailhot wrote:

>  For Go modules, that will become the default upstream in August,
> Google
>  invented holed BuildRequires version ranges:
>  – anything starting with version
>  – except a list of specific version exclusions (not exclusion ranges,
>  specific versions)
>  
>  Basically upstreams are allowed to declare incompatible versions, but
>  Google would really like them to keep ascendent API compatibility
>  (and Google requires module renaming on major version changes, so there
>  is no upper limit to the API compatibility)
>  
>  Is the correct way to represent those in rpm:
>  
>  BuildRequires: ((golang-module(github.com/stretchr/testify) >= 1.3.0) and
> ((golang-module(github.com/stretchr/testify) < 1.3.2~0.20180906233101.161cd47e91fd) or
> (golang-module(github.com/stretchr/testify) > 1.3.2~0.20180906233101.161cd47e91fd)) and
> ((golang-module(github.com/stretchr/testify) < 1.3.2~1.pre1) or
> (golang-module(github.com/stretchr/testify) > 1.3.2~1.pre1)) and
> ((golang-module(github.com/stretchr/testify) <
> 1.3.2~1.pre1.0.20180628173108.788fd7840127) or (golang-module(github.com/stretchr/testify)
> > 1.3.2~1.pre1.0.20180628173108.788fd7840127)))
>  
>  or am I missing something obvious? 
Well using and/or is wrong to start with because they allow the
different conditions to be satisfied by different packages.

I think something like this would work:

BuildRequires: (x >= 1.3.0 without x = 1.3.2 without x = 1.3.4)

That requires a single package that meets the first condition
but not either of the other two conditions if I'm reading the
documentation correctly.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Nicolas Mailhot]

Le vendredi 29 mars 2019 à 22:25 +0000, Tom Hughes a écrit :
>  
>  I think something like this would work:
>  
>  BuildRequires: (x >= 1.3.0 without x = 1.3.2 without x = 1.3.4)
>  
>  That requires a single package that meets the first condition
>  but not either of the other two conditions if I'm reading the
>  documentation correctly. 
Thanks for the suggestion. That may work indeed, depending on rpm
operator priority. To be sure, you'd need lots of lispy parenthesis (as
the rpm documentation seems to recommend).

((((x >= 1.3.0) without x = 1.3.2) without (x = 1.3.4)) without (x = 1.5.7)

Unfortunately both solutions (no parenthesis, cross fingers, lots of
parenthesis, sure result) are quite human unfriendly.

So I'm going to try

((x >= 1.3.0) without ((x = 1.3.2) or (x = 1.3.4) or (x = 1.5.7)))

which is sure to work semantically, and is more regular and human-
friendly

Of course sure to work semantically does not means sure to work as
implemented in the solver. Will need testing

I anyone has better ideas…


Regards,

-- 
Nicolas Mailhot

[Tom Hughes]

On 30/03/2019 08:27, Nicolas Mailhot wrote:

>  Thanks for the suggestion. That may work indeed, depending on rpm
>  operator priority. To be sure, you'd need lots of lispy parenthesis (as
>  the rpm documentation seems to recommend).
>  
>  ((((x >= 1.3.0) without x = 1.3.2) without (x = 1.3.4)) without (x = 1.5.7)
>  
>  Unfortunately both solutions (no parenthesis, cross fingers, lots of
>  parenthesis, sure result) are quite human unfriendly. 
The page I saw was explicit that repeated and/or didn't need
parens and I assumed that extended to with/without which were
introduced more recently:

https://rpm.org/user_doc/boolean_dependencies.html#nesting

>  So I'm going to try
>  
>  ((x >= 1.3.0) without ((x = 1.3.2) or (x = 1.3.4) or (x = 1.5.7)))
>  
>  which is sure to work semantically, and is more regular and human-
>  friendly 
Does that work, given that or allows different packages to
match different branches of the condition?

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Nico Kadel-Garcia]

On Sat, Mar 30, 2019 at 4:27 AM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le vendredi 29 mars 2019 à 22:25 +0000, Tom Hughes a écrit :
>  >
>  > I think something like this would work:
>  >
>  > BuildRequires: (x >= 1.3.0 without x = 1.3.2 without x = 1.3.4)
>  >
>  > That requires a single package that meets the first condition
>  > but not either of the other two conditions if I'm reading the
>  > documentation correctly.
>
>  Thanks for the suggestion. That may work indeed, depending on rpm
>  operator priority. To be sure, you'd need lots of lispy parenthesis (as
>  the rpm documentation seems to recommend).
>
>  ((((x >= 1.3.0) without x = 1.3.2) without (x = 1.3.4)) without (x = 1.5.7)
>
>  Unfortunately both solutions (no parenthesis, cross fingers, lots of
>  parenthesis, sure result) are quite human unfriendly. 
For legibly and supporting updates, Don't. With a capital D. Just
write 3 distinct statements.

BuildRequires: x >= 1.3.0
BuildRequires: x != 1.3.0
BuildRequires: x != 1.5.7

> So I'm going to try
>
> ((x >= 1.3.0) without ((x = 1.3.2) or (x = 1.3.4) or (x = 1.5.7)))
>
> which is sure to work semantically, and is more regular and human-
> friendly
>
> Of course sure to work semantically does not means sure to work as
> implemented in the solver. Will need testing
>
> I anyone has better ideas…
>
>
> Regards,
>
> --
> Nicolas Mailhot
> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
https://lists.fedoraproject.org/archives/list/[e-mail]...

[Tom Hughes]

On 30/03/2019 17:08, Nico Kadel-Garcia wrote:
>  On Sat, Mar 30, 2019 at 4:27 AM Nicolas Mailhot
>  <nicolas.mailhot(a)laposte.net&gt; wrote:
>
> > Thanks for the suggestion. That may work indeed, depending on rpm
> > operator priority. To be sure, you'd need lots of lispy parenthesis (as
> > the rpm documentation seems to recommend).
> >
> > ((((x >= 1.3.0) without x = 1.3.2) without (x = 1.3.4)) without (x = 1.5.7)
> >
> > Unfortunately both solutions (no parenthesis, cross fingers, lots of
> > parenthesis, sure result) are quite human unfriendly.
>  
>  For legibly and supporting updates, Don't. With a capital D. Just
>  write 3 distinct statements.
>  
>  BuildRequires: x >= 1.3.0
>  BuildRequires: x != 1.3.0
>  BuildRequires: x != 1.5.7 
Is != actually supported? It's not mentioned in the documentation:

   https://rpm.org/user_doc/dependencies.html#requires

Also that construction allows different packages to satisfy each
require rather than ensuring that a single package matches them
all. It's only an issue if multiple versions are being packaged
but it does need to be considered.

Tom

-- 
Tom Hughes (tom(a)compton.nu)
http://compton.nu/

[Nicolas Mailhot]

Le samedi 30 mars 2019 à 09:59 +0000, Tom Hughes a écrit :
>  On 30/03/2019 08:27, Nicolas Mailhot wrote:
>  
>  > Thanks for the suggestion. That may work indeed, depending on rpm
>  > operator priority. To be sure, you'd need lots of lispy parenthesis
>  > (as
>  > the rpm documentation seems to recommend).
>  > 
>  > ((((x >= 1.3.0) without x = 1.3.2) without (x = 1.3.4)) without (x
>  > = 1.5.7)
>  > 
>  > Unfortunately both solutions (no parenthesis, cross fingers, lots
>  > of
>  > parenthesis, sure result) are quite human unfriendly.
>  
>  The page I saw was explicit that repeated and/or didn't need
>  parens and I assumed that extended to with/without which were
>  introduced more recently:
>  
>  https://rpm.org/user_doc/boolean_dependencies.html#nesting 
Alsmost all the examples here are without version qualifiers, it's not
clear what is their precedence WRT the other operators 

>  
>  > So I'm going to try
>  > 
>  > ((x >= 1.3.0) without ((x = 1.3.2) or (x = 1.3.4) or (x = 1.5.7)))
>  > 
>  > which is sure to work semantically, and is more regular and human-
>  > friendly
>  
>  Does that work, given that or allows different packages to
>  match different branches of the condition? 
If rpm honors the global parenthesis around the or block it should
(famous last words)

-- 
Nicolas Mailhot

[Nico Kadel-Garcia]

On Sat, Mar 30, 2019 at 3:40 PM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net&gt; wrote:
>  Le samedi 30 mars 2019 à 09:59 +0000, Tom Hughes a écrit :
>  > On 30/03/2019 08:27, Nicolas Mailhot wrote:
>  >
>  > > Thanks for the suggestion. That may work indeed, depending on rpm
>  > > operator priority. To be sure, you'd need lots of lispy parenthesis
>  > > (as
>  > > the rpm documentation seems to recommend).
>  > >
>  > > ((((x >= 1.3.0) without x = 1.3.2) without (x = 1.3.4)) without (x
>  > > = 1.5.7) 
Come to think of it, I'd normally use:

BuildRequires: x >= 1.3.0
Conflicts: x = 1.3.2
Conflicts: x = 1.3.4

Life can get.... interesting, if "x" is a "Provides:" element rather
than the actual name of the package, such as those for java, python
modules, or perl modules.

[Jakub Cajka]

----- Original Message -----
>  From: "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt;
>  To: packaging(a)lists.fedoraproject.org
>  Sent: Friday, March 29, 2019 8:33:39 PM
>  Subject: [Fedora-packaging] Translating Go modules buildrequires in rpm syntax
>  
>  Hi,
>  
>  For Go modules, that will become the default upstream in August, Google
>  invented holed BuildRequires version ranges:
>  – anything starting with version
>  – except a list of specific version exclusions (not exclusion ranges,
>  specific versions)
>  
>  Basically upstreams are allowed to declare incompatible versions, but
>  Google would really like them to keep ascendent API compatibility
>  (and Google requires module renaming on major version changes, so there
>  is no upper limit to the API compatibility)
>   
As I perceive this might be perceived by you as my personal attack I want to be clear that
this is just my take on it and my technical opinion, so please keep this in mind. I would
like to avoid any unnecessary misunderstandings and conflicts.

But do we really need to recreate everything that upstream put in to the constrains in
specs? I think that we are carrying curated set of the packages so this is IMHO not really
necessary(at least not in all cases, just ones that crept in to our package base and we
should avoid them at all costs). 

IMO if there are "holes" in the versions we should work with the upstreams to
mitigate(fix) them and I believe they will be probably for some past/intermittent
versions(do you have actual cases to show as examples?) and we can pretty easily handle
them preventively with conflicts statements and proper comments accompanying them like
"Based on constrain in the module ... caused by ...". Or is this something that
is not possible/feasible?

Do you have any cases where we will have to carry them in 1:1 representation with current
package set?

JC

PS: CC'ing wider Fedora's Go community

> Is the correct way to represent those in rpm:
> 
> BuildRequires: ((golang-module(github.com/stretchr/testify) >= 1.3.0) and
> ((golang-module(github.com/stretchr/testify) <
> 1.3.2~0.20180906233101.161cd47e91fd) or
> (golang-module(github.com/stretchr/testify) >
> 1.3.2~0.20180906233101.161cd47e91fd)) and
> ((golang-module(github.com/stretchr/testify) < 1.3.2~1.pre1) or
> (golang-module(github.com/stretchr/testify) > 1.3.2~1.pre1)) and
> ((golang-module(github.com/stretchr/testify) <
> 1.3.2~1.pre1.0.20180628173108.788fd7840127) or
> (golang-module(github.com/stretchr/testify) >
> 1.3.2~1.pre1.0.20180628173108.788fd7840127)))
> 
> or am I missing something obvious?
> 
> Best regards,
> 
> --
> Nicolas Mailhot
> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>

[Nicolas Mailhot]

Le 2019-04-02 10:04, Jakub Cajka a écrit :
Hi Jakub,

>  But do we really need to recreate everything that upstream put in to
>  the constrains in specs? I think that we are carrying curated set of
>  the packages so this is IMHO not really necessary(at least not in all
>  cases, just ones that crept in to our package base and we should avoid
>  them at all costs). 
We will have to diverge from upstream, that's an absolute certainty, the 
quality of upstream releases is just not good enough for direct 
packaging in many cases.

However, just because we will diverge on some points, does not mean we 
have to diverge everywhere. Diverging makes engaging with upstream hard.

In that particular case it is possible to represent perfectly the 
upstream notion of holed version ranges as rpm constrains, and the 
upstream notion of holed version ranges is quite sane and limited¹, so 
there's no reason not to translate it accurately by default.

The packager can patch out exclusions from the upstream go.mod file in 
%prep if he finds them problematic.

Alternatively, he can add a sed (or other) filter to the buildrequires 
generator output, that's perfectly allowed by the 
https://github.com/rpm-software-management/rpm/issues/104 design.

Things like module replaces will be a lot more tricky to handle, and 
will almost always require packager decisions when present in upstream 
module files.

Likewise, things like “every file in the Go module participates in go 
module requirements, including tests and other os support files” will be 
awful for us and will require fine-grained file removal in %prep. We 
won't be able to install broken files and pretend they're not here like 
today (I warned against install-but-pretend-it’s-not-here strategies at 
the last SIG meeting, precisely because Go modules won’t let us do it 
free of deps).

So, don’t fret, we *will* diverge form upstream, just not on exclusions, 
unless we have to.

¹ Projects have to declare every single code state they want to 
blacklist, they can not issue blanket exclusion range statements, it's 
real blacklisting not “I don't want to look at other versions” stuff

-- 
Nicolas Mailhot

[Jakub Cajka]

----- Original Message -----
>  From: "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt;
>  To: golang(a)lists.fedoraproject.org
>  Cc: "Discussion of RPM packaging standards and practices for Fedora"
> <packaging(a)lists.fedoraproject.org&gt;
>  Sent: Tuesday, April 2, 2019 12:07:58 PM
>  Subject: [Fedora-packaging] Re: Translating Go modules buildrequires in rpm syntax
>  
>  Le 2019-04-02 10:04, Jakub Cajka a écrit :
>  Hi Jakub,
>  
>  > But do we really need to recreate everything that upstream put in to
>  > the constrains in specs? I think that we are carrying curated set of
>  > the packages so this is IMHO not really necessary(at least not in all
>  > cases, just ones that crept in to our package base and we should avoid
>  > them at all costs).
>  
>  We will have to diverge from upstream, that's an absolute certainty, the
>  quality of upstream releases is just not good enough for direct
>  packaging in many cases.
>  
>  However, just because we will diverge on some points, does not mean we
>  have to diverge everywhere. Diverging makes engaging with upstream hard.
>  
>  In that particular case it is possible to represent perfectly the
>  upstream notion of holed version ranges as rpm constrains, and the
>  upstream notion of holed version ranges is quite sane and limited¹, so
>  there's no reason not to translate it accurately by default.
>  
>  The packager can patch out exclusions from the upstream go.mod file in
>  %prep if he finds them problematic.
>  
>  Alternatively, he can add a sed (or other) filter to the buildrequires
>  generator output, that's perfectly allowed by the
>  https://github.com/rpm-software-management/rpm/issues/104 design.
>  
>  Things like module replaces will be a lot more tricky to handle, and
>  will almost always require packager decisions when present in upstream
>  module files.
>  
>  Likewise, things like “every file in the Go module participates in go
>  module requirements, including tests and other os support files” will be
>  awful for us and will require fine-grained file removal in %prep. We
>  won't be able to install broken files and pretend they're not here like
>  today (I warned against install-but-pretend-it’s-not-here strategies at
>  the last SIG meeting, precisely because Go modules won’t let us do it
>  free of deps).
>  
>  So, don’t fret, we *will* diverge form upstream, just not on exclusions,
>  unless we have to.
>  
>  ¹ Projects have to declare every single code state they want to
>  blacklist, they can not issue blanket exclusion range statements, it's
>  real blacklisting not “I don't want to look at other versions” stuff
>  
>  --
>  Nicolas Mailhot 
I might have not been clear, sorry. My point is more that we don't need to
recreate/capture the constrains in the spec files/RPM as they are already capture in the
Go source code, creating part that needs to be (manually) maintained up to date, while the
GC tooling will enforce them anyway. We will have to workaround those constrains
eventually in some cases, for sure as you outlined, but we don't need to IMHO
"waste" time on mapping them 1:1 in to the RPM world, with RPM constrains.

JC

> _______________________________________________
> packaging mailing list -- packaging(a)lists.fedoraproject.org
> To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>

[Nicolas Mailhot]

Le 2019-04-02 12:52, Jakub Cajka a écrit :

>  I might have not been clear, sorry. My point is more that we
> don't
>  need to recreate/capture the constrains in the spec files/RPM as they
>  are already capture in the Go source code, 
In the Go module world the constrains are in the module files, not in 
the source files. If you don't satisfy the constrains in your build root 
lots of go commands will break. So you better tell the rpm tooling what 
the constrains are so build roots are populated correctly.

>  creating part that needs to be (manually) maintained up to date,
There's nothing to maintain manually if you integrate properly with rpm. 
That's why spec generators like gofed, that try to avoid the rpm 
integration part, do not pass the maintainability test.

Integrating properly means
https://github.com/rpm-software-management/rpm/issues/104

>  while the GC tooling will enforce them anyway. 
ie builds will fail because the build environment is not populated 
correctly. It'd rather populate it automatically and correctly by 
default than wait for builds to fail and then spend time on manual 
workarounds because the tooling does not help me.

-- 
Nicolas Mailhot

[Jakub Cajka]

----- Original Message -----
>  From: "Nicolas Mailhot"
> <nicolas.mailhot(a)laposte.net&gt;
>  To: "Discussion of RPM packaging standards and practices for Fedora"
> <packaging(a)lists.fedoraproject.org&gt;
>  Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka" <jcajka(a)redhat.com&gt;
>  Sent: Tuesday, April 2, 2019 1:27:09 PM
>  Subject: Re: [Fedora-packaging] Re: Translating Go modules buildrequires in rpm syntax
>  
>  Le 2019-04-02 12:52, Jakub Cajka a écrit :
>  
>  > I might have not been clear, sorry. My point is more that we don't
>  > need to recreate/capture the constrains in the spec files/RPM as they
>  > are already capture in the Go source code,
>  
>  In the Go module world the constrains are in the module files, not in
>  the source files. If you don't satisfy the constrains in your build root
>  lots of go commands will break. So you better tell the rpm tooling what
>  the constrains are so build roots are populated correctly.
>   
And they are part of the checked in source tree of the respective Go project, if I'm
not mistaken.

>  > creating part that needs to be (manually) maintained up to
> date,
>  
>  There's nothing to maintain manually if you integrate properly with rpm.
>  That's why spec generators like gofed, that try to avoid the rpm
>  integration part, do not pass the maintainability test.
>  
>  Integrating properly means
>  https://github.com/rpm-software-management/rpm/issues/104 

Which is not yet there, right?

>  
>  > while the GC tooling will enforce them anyway.
>  
>  ie builds will fail because the build environment is not populated
>  correctly. It'd rather populate it automatically and correctly by
>  default than wait for builds to fail and then spend time on manual
>  workarounds because the tooling does not help me.
>   
Great to hear that you are working on the packaging automation.

JC

> --
> Nicolas Mailhot
>

[Nicolas Mailhot]

Le 2019-04-02 14:51, Jakub Cajka a écrit :
>  ----- Original Message -----
> > From: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
> > To: "Discussion of RPM packaging standards and practices for Fedora" 
> > <packaging(a)lists.fedoraproject.org&gt;
> > Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka"
> <jcajka(a)redhat.com&gt;
> > Sent: Tuesday, April 2, 2019 1:27:09 PM
> > Subject: Re: [Fedora-packaging] Re: Translating Go modules 
> > buildrequires in rpm syntax
> > 
> > Le 2019-04-02 12:52, Jakub Cajka a écrit :
> > 
> > > I might have not been clear, sorry. My point is more that we don't
> > > need to recreate/capture the constrains in the spec files/RPM as they
> > > are already capture in the Go source code,
> > 
> > In the Go module world the constrains are in the module files, not in
> > the source files. If you don't satisfy the constrains in your build 
> > root
> > lots of go commands will break. So you better tell the rpm tooling 
> > what
> > the constrains are so build roots are populated correctly.
>  
>  And they are part of the checked in source tree of the respective Go
>  project, if I'm not mistaken. 
And upstream tools check and regenerate the go.mod file at the slightest 
occasion.

So, basically, having rpm parse exactly this file is not a problem, 
because if a packager disagrees with the content of this file, but does 
not fix/patch it, go tools will ignore the packager and obey the go.mod 
file anyway.

> > > creating part that needs to be (manually) maintained up to
> date,
> > 
> > There's nothing to maintain manually if you integrate properly with 
> > rpm.
> > That's why spec generators like gofed, that try to avoid the rpm
> > integration part, do not pass the maintainability test.
> > 
> > Integrating properly means
> > https://github.com/rpm-software-management/rpm/issues/104
>  
>  Which is not yet there, right? 
Which is being worked on by rpm upstream, just like I'm working on the 
corresponding generator for go modules (we already have a generator for 
pre-module world, even though it is based on golist not the dep analysis 
upstream created for go modules).

No having a generator at Go module time will mean every Go packager will 
have to perform go.mod analysis and translation to rpm deps manually, 
for every single Go project we package.

-- 
Nicolas Mailhot

[Igor Gnatenko]

On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot <nicolas.mailhot(a)laposte.net&gt;
wrote:

>  Le 2019-04-02 14:51, Jakub Cajka a écrit :
>  > ----- Original Message -----
>  >> From: "Nicolas Mailhot" <nicolas.mailhot(a)laposte.net&gt;
>  >> To: "Discussion of RPM packaging standards and practices for Fedora"
>  >> <packaging(a)lists.fedoraproject.org&gt;
>  >> Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka"
> <jcajka(a)redhat.com&gt;
>  >> Sent: Tuesday, April 2, 2019 1:27:09 PM
>  >> Subject: Re: [Fedora-packaging] Re: Translating Go modules
>  >> buildrequires in rpm syntax
>  >>
>  >> Le 2019-04-02 12:52, Jakub Cajka a écrit :
>  >>
>  >> > I might have not been clear, sorry. My point is more that we don't
>  >> > need to recreate/capture the constrains in the spec files/RPM as they
>  >> > are already capture in the Go source code,
>  >>
>  >> In the Go module world the constrains are in the module files, not in
>  >> the source files. If you don't satisfy the constrains in your build
>  >> root
>  >> lots of go commands will break. So you better tell the rpm tooling
>  >> what
>  >> the constrains are so build roots are populated correctly.
>  >
>  > And they are part of the checked in source tree of the respective Go
>  > project, if I'm not mistaken.
>
>  And upstream tools check and regenerate the go.mod file at the slightest
>  occasion.
>
>  So, basically, having rpm parse exactly this file is not a problem,
>  because if a packager disagrees with the content of this file, but does
>  not fix/patch it, go tools will ignore the packager and obey the go.mod
>  file anyway.
>  
I usually disagree with Nicolas, but this is the point where he gets +100
from me. Reflecting upstream constraints in RPM is essential. People do not
just use distro repos, they build their own packages and such. In this
case, we should be very strict about what content should be in buildroot
and on user's systems. Otherwise you will get a lot of bugreports like
"this golang module doesn't compile since last update" (which is because we
didn't have proper info in RPM requires).

[Jakub Cajka]

----- Original Message -----
>  From: "Igor Gnatenko"
> <ignatenkobrain(a)fedoraproject.org&gt;
>  To: "Discussion of RPM packaging standards and practices for Fedora"
> <packaging(a)lists.fedoraproject.org&gt;
>  Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka" <jcajka(a)redhat.com&gt;
>  Sent: Tuesday, April 2, 2019 6:40:27 PM
>  Subject: Re: [Fedora-packaging] Re: Translating Go modules buildrequires in rpm syntax
>  
>  On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot < nicolas.mailhot(a)laposte.net
>  > wrote:
>  
>  
>  Le 2019-04-02 14:51, Jakub Cajka a écrit :
>  > ----- Original Message -----
>  >> From: "Nicolas Mailhot" < nicolas.mailhot(a)laposte.net >
>  >> To: "Discussion of RPM packaging standards and practices for Fedora"
>  >> < packaging(a)lists.fedoraproject.org >
>  >> Cc: golang(a)lists.fedoraproject.org , "Jakub Cajka" <
> jcajka(a)redhat.com >
>  >> Sent: Tuesday, April 2, 2019 1:27:09 PM
>  >> Subject: Re: [Fedora-packaging] Re: Translating Go modules
>  >> buildrequires in rpm syntax
>  >> 
>  >> Le 2019-04-02 12:52, Jakub Cajka a écrit :
>  >> 
>  >> > I might have not been clear, sorry. My point is more that we don't
>  >> > need to recreate/capture the constrains in the spec files/RPM as they
>  >> > are already capture in the Go source code,
>  >> 
>  >> In the Go module world the constrains are in the module files, not in
>  >> the source files. If you don't satisfy the constrains in your build
>  >> root
>  >> lots of go commands will break. So you better tell the rpm tooling
>  >> what
>  >> the constrains are so build roots are populated correctly.
>  > 
>  > And they are part of the checked in source tree of the respective Go
>  > project, if I'm not mistaken.
>  
>  And upstream tools check and regenerate the go.mod file at the slightest
>  occasion.
>  
>  So, basically, having rpm parse exactly this file is not a problem,
>  because if a packager disagrees with the content of this file, but does
>  not fix/patch it, go tools will ignore the packager and obey the go.mod
>  file anyway.
>  
>  I usually disagree with Nicolas, but this is the point where he gets +100
>  from me. Reflecting upstream constraints in RPM is essential. People do not
>  just use distro repos, they build their own packages and such. In this case,
>  we should be very strict about what content should be in buildroot and on
>  user's systems. Otherwise you will get a lot of bugreports like "this golang
>  module doesn't compile since last update" (which is because we didn't have
>  proper info in RPM requires). 
Actually same here as he is mentioning that he is working on the packaging automation.
Without it IMO would be case for concerns. With it, it is awesome and I'm looking
forward to it. 

JC

> 
> _______________________________________________
> golang mailing list -- golang(a)lists.fedoraproject.org
> To unsubscribe send an email to golang-leave(a)lists.fedoraproject.org
> Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]
>

[Neal Gompa]

On Wed, Apr 3, 2019 at 3:26 AM Jakub Cajka <jcajka(a)redhat.com&gt; wrote:
>  ----- Original Message -----
>  > From: "Igor Gnatenko" <ignatenkobrain(a)fedoraproject.org&gt;
>  > To: "Discussion of RPM packaging standards and practices for Fedora"
> <packaging(a)lists.fedoraproject.org&gt;
>  > Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka"
> <jcajka(a)redhat.com&gt;
>  > Sent: Tuesday, April 2, 2019 6:40:27 PM
>  > Subject: Re: [Fedora-packaging] Re: Translating Go modules buildrequires in rpm
> syntax
>  >
>  > On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot < nicolas.mailhot(a)laposte.net
>  > > wrote:
>  >
>  >
>  > Le 2019-04-02 14:51, Jakub Cajka a écrit :
>  > > ----- Original Message -----
>  > >> From: "Nicolas Mailhot" < nicolas.mailhot(a)laposte.net >
>  > >> To: "Discussion of RPM packaging standards and practices for
> Fedora"
>  > >> < packaging(a)lists.fedoraproject.org >
>  > >> Cc: golang(a)lists.fedoraproject.org , "Jakub Cajka" <
> jcajka(a)redhat.com >
>  > >> Sent: Tuesday, April 2, 2019 1:27:09 PM
>  > >> Subject: Re: [Fedora-packaging] Re: Translating Go modules
>  > >> buildrequires in rpm syntax
>  > >>
>  > >> Le 2019-04-02 12:52, Jakub Cajka a écrit :
>  > >>
>  > >> > I might have not been clear, sorry. My point is more that we
> don't
>  > >> > need to recreate/capture the constrains in the spec files/RPM as they
>  > >> > are already capture in the Go source code,
>  > >>
>  > >> In the Go module world the constrains are in the module files, not in
>  > >> the source files. If you don't satisfy the constrains in your build
>  > >> root
>  > >> lots of go commands will break. So you better tell the rpm tooling
>  > >> what
>  > >> the constrains are so build roots are populated correctly.
>  > >
>  > > And they are part of the checked in source tree of the respective Go
>  > > project, if I'm not mistaken.
>  >
>  > And upstream tools check and regenerate the go.mod file at the slightest
>  > occasion.
>  >
>  > So, basically, having rpm parse exactly this file is not a problem,
>  > because if a packager disagrees with the content of this file, but does
>  > not fix/patch it, go tools will ignore the packager and obey the go.mod
>  > file anyway.
>  >
>  > I usually disagree with Nicolas, but this is the point where he gets +100
>  > from me. Reflecting upstream constraints in RPM is essential. People do not
>  > just use distro repos, they build their own packages and such. In this case,
>  > we should be very strict about what content should be in buildroot and on
>  > user's systems. Otherwise you will get a lot of bugreports like "this
> golang
>  > module doesn't compile since last update" (which is because we didn't
> have
>  > proper info in RPM requires).
>
>  Actually same here as he is mentioning that he is working on the packaging automation.
> Without it IMO would be case for concerns. With it, it is awesome and I'm looking
> forward to it.
>  
To the original query, how I see it is that our (Build)Requires should
structure as accordingly:

BuildRequires: (golang-module(foo) >= 1.0.0 unless (golang-module(foo)
= 1.1.5 or golang-module(foo) = 1.2.0))



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Igor Gnatenko]

s/unless/without/

And then it looks good.

On Wed, Apr 3, 2019 at 2:19 PM Neal Gompa <ngompa13(a)gmail.com&gt; wrote:

>  On Wed, Apr 3, 2019 at 3:26 AM Jakub Cajka <jcajka(a)redhat.com&gt;
> wrote:
>  >
>  >
>  >
>  >
>  >
>  > ----- Original Message -----
>  > > From: "Igor Gnatenko" <ignatenkobrain(a)fedoraproject.org&gt;
>  > > To: "Discussion of RPM packaging standards and practices for Fedora"
> <
>  packaging(a)lists.fedoraproject.org&gt;
>  > > Cc: golang(a)lists.fedoraproject.org, "Jakub Cajka"
> <jcajka(a)redhat.com&gt;
>  > > Sent: Tuesday, April 2, 2019 6:40:27 PM
>  > > Subject: Re: [Fedora-packaging] Re: Translating Go modules
>  buildrequires in rpm syntax
>  > >
>  > > On Tue, Apr 2, 2019 at 6:17 PM Nicolas Mailhot <
>  nicolas.mailhot(a)laposte.net
>  > > > wrote:
>  > >
>  > >
>  > > Le 2019-04-02 14:51, Jakub Cajka a écrit :
>  > > > ----- Original Message -----
>  > > >> From: "Nicolas Mailhot" < nicolas.mailhot(a)laposte.net
> >
>  > > >> To: "Discussion of RPM packaging standards and practices for
> Fedora"
>  > > >> < packaging(a)lists.fedoraproject.org >
>  > > >> Cc: golang(a)lists.fedoraproject.org , "Jakub Cajka" <
>  jcajka(a)redhat.com >
>  > > >> Sent: Tuesday, April 2, 2019 1:27:09 PM
>  > > >> Subject: Re: [Fedora-packaging] Re: Translating Go modules
>  > > >> buildrequires in rpm syntax
>  > > >>
>  > > >> Le 2019-04-02 12:52, Jakub Cajka a écrit :
>  > > >>
>  > > >> > I might have not been clear, sorry. My point is more that we
> don't
>  > > >> > need to recreate/capture the constrains in the spec files/RPM as
>  they
>  > > >> > are already capture in the Go source code,
>  > > >>
>  > > >> In the Go module world the constrains are in the module files, not
>  in
>  > > >> the source files. If you don't satisfy the constrains in your
> build
>  > > >> root
>  > > >> lots of go commands will break. So you better tell the rpm tooling
>  > > >> what
>  > > >> the constrains are so build roots are populated correctly.
>  > > >
>  > > > And they are part of the checked in source tree of the respective Go
>  > > > project, if I'm not mistaken.
>  > >
>  > > And upstream tools check and regenerate the go.mod file at the
>  slightest
>  > > occasion.
>  > >
>  > > So, basically, having rpm parse exactly this file is not a problem,
>  > > because if a packager disagrees with the content of this file, but does
>  > > not fix/patch it, go tools will ignore the packager and obey the go.mod
>  > > file anyway.
>  > >
>  > > I usually disagree with Nicolas, but this is the point where he gets
>  +100
>  > > from me. Reflecting upstream constraints in RPM is essential. People
>  do not
>  > > just use distro repos, they build their own packages and such. In this
>  case,
>  > > we should be very strict about what content should be in buildroot and
>  on
>  > > user's systems. Otherwise you will get a lot of bugreports like "this
>  golang
>  > > module doesn't compile since last update" (which is because we
> didn't
>  have
>  > > proper info in RPM requires).
>  >
>  > Actually same here as he is mentioning that he is working on the
>  packaging automation. Without it IMO would be case for concerns. With it,
>  it is awesome and I'm looking forward to it.
>  >
>
>  To the original query, how I see it is that our (Build)Requires should
>  structure as accordingly:
>
>  BuildRequires: (golang-module(foo) >= 1.0.0 unless (golang-module(foo)
>  = 1.1.5 or golang-module(foo) = 1.2.0))
>
>
>
>  --
>  真実はいつも一つ！/ Always, there's only one truth!
>  _______________________________________________
>  packaging mailing list -- packaging(a)lists.fedoraproject.org
>  To unsubscribe send an email to packaging-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]...
>

[Neal Gompa]

On Wed, Apr 3, 2019 at 7:20 AM Igor Gnatenko
<ignatenkobrain(a)fedoraproject.org&gt; wrote:
>  s/unless/without/
>
>  And then it looks good.
>  
Sorry, you're right. :)


-- 
真実はいつも一つ！/ Always, there's only one truth!

[Nicolas Mailhot]

Le mercredi 03 avril 2019 à 07:17 -0500, Neal Gompa a écrit :
>  
>  To the original query, how I see it is that our (Build)Requires
>  should
>  structure as accordingly:
>  
>  BuildRequires: (golang-module(foo) >= 1.0.0 unless (golang-
>  module(foo)
>  = 1.1.5 or golang-module(foo) = 1.2.0)) 
So I should drop the parenthesis around version qualifiers? Works for
me

BuildRequires: (golang-module(foo) >= 1.0.0 without (golang-module(foo) = 1.1.5 or
golang-module(foo) = 1.2.0))

Trivia time: an interesting twist of the golang module design is that
exclusions do not propagate, they only apply in BuildRequires, not
Requires

(I'm curious how that will work out in practice, it feels too clever by
half, I don't see real-world devs understanding the implications, but
I’ll be happy to be proven wrong)

-- 
Nicolas Mailhot