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