----- Original Message ----- > From: "Nicolas Mailhot" <nicolas.mailhot@xxxxxxxxxxx> > To: golang@xxxxxxxxxxxxxxxxxxxxxxx > Cc: "Discussion of RPM packaging standards and practices for Fedora" <packaging@xxxxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ packaging mailing list -- packaging@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to packaging-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
