2:33 p.m.
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
4:54 p.m.
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
5:25 p.m.
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/
3:27 a.m.
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
4:59 a.m.
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/
2:39 p.m.
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
4:39 p.m.
New subject: Translating Go modules buildrequires in rpm syntax
On Sat, Mar 30, 2019 at 3:40 PM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> 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.
12:08 p.m.
New subject: Translating Go modules buildrequires in rpm syntax
On Sat, Mar 30, 2019 at 4:27 AM Nicolas Mailhot
<nicolas.mailhot(a)laposte.net> 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/packaging@lists.fedoraproje...
12:24 p.m.
New subject: Translating Go modules buildrequires in rpm syntax
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> 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/
3:04 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
----- Original Message -----
From: "Nicolas Mailhot"
<nicolas.mailhot(a)laposte.net>
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/packaging@lists.fedoraproje...
>
5:07 a.m.
New subject: 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
5:52 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
----- Original Message -----
From: "Nicolas Mailhot"
<nicolas.mailhot(a)laposte.net>
To: golang(a)lists.fedoraproject.org
Cc: "Discussion of RPM packaging standards and practices for Fedora"
<packaging(a)lists.fedoraproject.org>
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/packaging@lists.fedoraproje...
>
6:27 a.m.
New subject: 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.
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
7:51 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
----- 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.
> 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
>
11:17 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
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.
> > 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
11:40 a.m.
New subject: 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).
3:26 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
----- Original Message -----
From: "Igor Gnatenko"
<ignatenkobrain(a)fedoraproject.org>
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 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/golang@lists.fedoraproject.org
>
7:17 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
On Wed, Apr 3, 2019 at 3:26 AM Jakub Cajka <jcajka(a)redhat.com> wrote:
----- Original Message -----
> From: "Igor Gnatenko" <ignatenkobrain(a)fedoraproject.org>
> 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 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!
7:19 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
s/unless/without/
And then it looks good.
On Wed, Apr 3, 2019 at 2:19 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Wed, Apr 3, 2019 at 3:26 AM Jakub Cajka <jcajka(a)redhat.com>
wrote:
>
>
>
>
>
> ----- Original Message -----
> > From: "Igor Gnatenko" <ignatenkobrain(a)fedoraproject.org>
> > 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 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/packaging@lists.fedoraproje...
7:33 a.m.
New subject: Translating Go modules buildrequires in rpm syntax
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
1849
days inactive
1854
days old
packaging@lists.fedoraproject.org
20 comments
6 participants
participants (6)
-
Igor Gnatenko -
Jakub Cajka -
Neal Gompa -
Nico Kadel-Garcia -
Nicolas Mailhot -
Tom Hughes