On 18. 12. 21 9:11, Alejandro Saez Morollon wrote:
On Tue, Dec 14, 2021 at 5:01 AM Matthew Miller <mat...@fedoraproject.org
<mailto:mat...@fedoraproject.org>> wrote:
On Mon, Dec 13, 2021 at 02:22:24PM +0100, Alejandro Saez Morollon wrote:
> A hypothetical new release cycle would look like this:
>
> - Fedora N release follows Go upstream as close as we can.
> - Fedora N-1 sticks with the latest major version of Go that was
> available on it until the release of Fedora N.
>
>
> Another hypothetical approach could be using modules with each upstream
> supported release in a stream.
This seems like the thing Modularity was invented to do, and would have the
advantage of being able to be consistent across a release with a
"baseline" version but also provide options.
But AFAIK, only users can select a module stream, right? I mean, packages can't
be build on top of a module stream
so new needs of package maintainers cannot be satisfy with modules.
I'm curious about how other SIGs deal with these scenarios...
In Python, we have one "main" Python version that remains the same within one
Fedora release. E.g. in Fedora 33 and 34 this was Python 3.9, while in Fedora
35 and 36 it is Python 3.10.
Other Python versions are provided for users to install via other python3.X
packages. Users of Fedora 35 can dnf install python3.9 and users of Fedora 34
can dnf install python3.10 (or python3.11 or python3.6 etc.).
https://developer.fedoraproject.org/tech/languages/python/multiple-pythons.html
The packages are parallel-installable -- users need to explicitly select what
Python they use, not what Python they install.
All Fedora Python packages are built with the "main" Python version, but the
reason for that is maintainability rather than necessity -- building for
multiple Python versions would mean we would need to build many (if not all)
libraries for different Python versions as well.
Go has an advantage because AFAIK it statically builds everything, so if
packagers choose to BuildRequire a different version of Go, they can do that in
a way that does not require mass changes of all the used libraries.
Similarly, Python needs to be installed in order to run Python code while Go
does not, so even if packaging parallel-installable versions of Go compiler is
not possible or reasonable, they can be packaged as conflicting packages.
There is no reason to package the alternate (newer or older) versions of Go as
modules. In fact, if you'd like other non-modular packages to be able to
BuildRequire different Go versions, modules won't work.
As a side note, modules are discouraged by policy if they can be avoided,
packagers SHOULD prefer "compatibility packages" (which is a term for what I
have described above):
https://docs.fedoraproject.org/en-US/modularity/policies/#_requirements_for_modules_in_fedora
Other languages do the same or similar thing as Python. E.g. clang and ghc
packages:
https://fedoraproject.org/wiki/Changes/GHC_parallel_version_installs
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
