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: