see also: https://firstname.lastname@example.org...
= On-demand Side Tags =
== Summary ==
Allow on-demand side tags, and allow packagers to a) tag whatever rpms
as build dependencies into those side tags, b) build packages they
want in those side tags, and then c) tag all or some of those new
packages back into appropriate “main” tag (e.g.
This new process will allow packagers to build rpms using older or
newer versions of build dependencies than the buildroot in a given
Fedora release, providing a subset of Modularity features in an
additive way (no influence on the way dependent packages are built or
installed). It may also coexist with Modularity in its current form.
As a policy change, default modules are disallowed and modules are only opt-in.
== Owners ==
* Name: [[User:Zbyszek| Zbigniew Jędrzejewski-Szmek]]
* Email: zbyszek at in.waw.pl
* Name: [[User:Churchyard| Miro Hrončok]]
== Detailed Description ==
=== Motivation ===
Modularity in its design and current implementation provides a number
of features that can be divided into two: for people ''building rpms
in modules'', and for people ''installing rpms from modules''. There
have been a number of issues, RFEs, and discussions about modularity,
but they are mostly about the second, user-facing part. Rpms installed
from modules interact with non-modular rpms, and of course every
aspect of this interaction is visible to users. To make Modularity a
success, we would not only need to make this interaction well-behaved,
we would also need to explain it to users in a satisfactory way.
The first part, module build internals, is not visible to users. Some
packagers don’t like the syntax, which is opaque and best-suited for
programmatic generation and consumption. Constant rebuilding of
modules also creates noticeable load on the infrastructure, making
everything else slower. If modularity became much more popular, and a
significant number of packagers was using it, we are convinced many
discussions would start about this first part too.
Despite some problems, there is clear demand for the features that
Modularity brings. In particular, we need some solution for the "too
fast too slow" problem, where some packages cannot update fast enough
to maintain compatibility with the rest of the distribution.
=== New approach: on-demand side tags ===
The new process proposed here provides an alternative to both parts of
The second part of Modularity is simply removed: '''users only get
normal rpms'''. After rpms have been built, some or all of them are
merged into the normal tags and delivered to users as usual. This is
pretty much the same as the usual rebuild of specific language or
graphic stacks in side tags that we do already. Dependencies between
rpms must be expressed using
The first part is replaced by a simpler scheme: '''we don’t define any
specific syntax or repositories to build packages'''. The packager has
to issue a sequence of 'fedpkg tag-build', 'fedpkg build', and 'koji
wait-repo' commands as appropriate (or 'fedpkg chain-build' or …). The
packager ''may'' link an older rpm into the side tag, allowing
building against old versions of packages. This means that if the
packager is not a committer to the package, they may only use a
version which was previously built in koji. The packager selects which
rpms should be merged back into the main tag. Old packages obviously
cannot be merged back.
To minimize disruption for users and current packagers, modules are
required to be opt-in only. There are no default modules and
non-modular rpms cannot depend for build or installation on modular
rpms. This way there is less burden to other packagers and Modularity
can evolve more easily.
=== Implementation ===
'''Ability to create side tags “on demand”, i.e. with an automated API
call''' must be implemented. Koji and other infra tools would need to
be able to deal with a large number of tags. Modularity already
creates a large number of tags, so this should not be a significant
Packager tools like fedpkg must grow '''new commands to create side tags'''.
Both the workflow in this proposal, and modules as they currently are
would be allowed to coexist. After we have some experience with both
approaches, one or both could be retired.
Since this proposal removes the possibility to have default modules,
'''modules need to be reset'''. The details are not specified yet. One
approach would be to do the equivalent of dnf module reset all during
upgrade to F32, similarly to the proposed solution for
This proposal assumes that '''fedpkg will be enhanced to do extended
chain builds smartly'''. This is not a precondition: even without that
packagers may script something that is appropriate for them. This is
one of the main advantages of the proposal: we put the “smarts” in
local tooling which can be enhanced and modified without breaking what
other packagers do. E.g. a solution to rebuild all 500 rust packages
with new versions may be significantly different than building a
compat version of postgresql, and that is OK.
=== Buildroot only packages ===
They are possible, because not all packages are merged back. The same
is currently possible with side tags, and with non-rawhide builds for
which packagers may never create a bodhi update, so there is no
fundamental change. Whether or not we need to disallow packages which
are purposefully buildroot-only by a policy is left out of this
proposal on purpose. Technically, it is possible.
== Benefit to Fedora ==
=== Costs, for packages converted from modules to this scheme ===
Transitional costs: according to this proposal, modules may still be
used. Nevertheless, if the contents of a module are to be used to
build normal rpms, that module will need to switch to the new process
or simply demodularized and built in the traditional way.
In the case where this happens, packaging would need to be
“translated” from module .yaml to normal spec files. This should
mostly be about adjusting metadata, i.e. package versions and
We would lose one of the main advertised features of Modularity: the
ability to build the same module in different versions. This might not
be a huge loss, for two reasons. First, great majority of modules are
single-version. Second, if desired it is possible to provide compat
packages with different names. This is a bit of annoying work, but we
have the process very well understood. Compat packages have the
additional advantage that they may be made co-installable (vide
python26, python2, python35, python36, python3, python38 packages
currently in F31). Compat packages are exempt from package review. We
may consider additional simplifications to the process to make compat
=== Benefits ===
Vast simplification for other packagers, i.e. those who would like to
depend on rpms which are currently modularized, and for users, who do
not have separate modular repos, just a single repo like before.
Reduced load on the build infrastructure.
Easier to find rpm sources because there again is one canonical repo.
Third parties building on top of Fedora can use our modules to build
their own rpms without trouble.
dnf does not need to handle complicated logic. It should be faster if
less repos are used.
Rpms are built against an up-to-date buildroot, with only the minimal
compat package inserted, instead of some
older-than-all-current-releases Fedora release.
Normal package-level package replacement and obsoletion mechanisms are used.
On-demand side tags will remove the need to open releng tickets to
have them manually created.
== Scope ==
* Proposal owners: detailed documentation how to do things in the new
scheme, client-side tooling improvements.
* Other developers: demodularize specific packages if wanted or necessary.
* Release engineering: implement the server side of side tags on
demand [RELENG TICKET WILL BE FILED LATER]
* Policies and guidelines: the docs would need to be added to packager
documentation. Pull requests will be submitted by proposal owners.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change should be fully additive to normal rpm packaging, so there
should be no upgrade/compatibility issues.
Some modules will need to be demodularized. This will require packager
work. Once this happens, rpms built this way will be fully available
to build normal rpms and modules, so the upgrade impact should be
limited to the modules being rewritten.
== How To Test a.k.a. examples of the new workflow ==
=== Version bump in a language stack ===
It is determined that a new set of rust rpm versions should be built.
A member of the rust-sig bumps the versions in dist-git for all
relevant packages, creates a side tag, and does the huge chain-build.
Once finished, this side tag is merged into rawhide-build. If desired,
it may also be merged into f31-updates-candidate and/or
f30-updates-candidate and bodhi updates submitted.
rust-sig already has tooling to generate the appropriate build-order
for modularity’s .yaml file. The same code can be reused to generate
the order for the chain build.
=== Three streams of a database package ===
A security patch needs to be applied to three versions of postgresql.
There are postgresql, postgresql82, postgresql81 dist-git repos. The
patch is added in dist-git for each of the packages, and they are
rebuilt as appropriate. Since we want to build each package with
different compiler versions, the packager uses a bash loop to schedule
separate builds of each of the three packages in each of the supported
(Once we have automatic creation of bodhi updates from koji builds,
the packager will not have to do anything more. Right now they still
need to create one big update that will then be split into separate
updates for each Fedora release.)
A small advantage compared to current modules is that packages are not
built against an already obsolete Fedora base, so users get the
benefit of toolchain improvements.
=== Package needs some old dep to build ===
Poor packager needs gcc-9.0, at the time where gcc-9.1 is the default
in the build root, to build koo. They bump the version of koo in
dist-git, create a side tag, tag old gcc-9.0-12.fc31 build into the
tag, build koo, merge the built package back into f32-build and
=== Package needs some old dep to install ===
koo-gui is only compatible with python3-qt5-5.12 when python3-qt5-5.13
has been released, and cannot be built with the new version. koo
maintainers may either a) arrange for python-qt5_5_12 compat package
to be created and then use it in the build root and as installation
dep, b) install old python3-qt5-5.12 package in build root, and bundle
some contents of that package into its output rpms, and add
=== FAQ for “other developers” ===
==== I maintain several modular streams of my package additionally to
the default version in Fedora. Can I keep doing this? ====
Yes, you can keep any alternate version in modular branches. When
appropriate, consider compat packages that can often be
co-installable, unlike modular streams.
==== I maintain my packages as modular only. Can I keep doing this? ====
Yes, as long as those modules are “leaves”, in the sense that no
non-modular rpms depend on them.
==== I would like to use an rpm which is currently only available as
module as a build dependency ====
The owner of the module should be asked to demodularize the module
(and either convert it to fully traditional rpms, or build some rpms
using the new side-tag process). Those rpms can then be used as build-
and installation-time dependencies.
If the owner of the module is not interested in providing non-modular
rpms, other packages may add such rpms to the distribution (and again
build them in one of the two ways).
==== Which rpms can be used as build dependencies in the side tag? ====
In principle, any rpm which is available in koji (including the
recursive dependencies, so it can actually be installed). In addition,
the packager may build rpms and use them in the side tag build root.
In practice, we expect that packagers will use one of the Fedora
releases (with updates), as the base.
== User Experience ==
Users have a clearer picture where their rpms are coming from. If they
opt-in into a module, they get some additional content. Without that,
they only get rpms from the normal Fedora repository. They are able to
rebuild rpms locally if there are no version conflicts. In case of
version conflicts, they might need to install older versions of rpms
from koji to satisfy the build (which might sound bad, but really
isn’t much different from current state with normal rpms.)
== Dependencies ==
On-demand side tags. Without this, this would be completely
infeasible. For limited and initial testing, side tags could be
== Contingency Plan ==
In the implementation phase, this should not impact other rpms in any
way (since it is change really happens on the build farm).
Once deployed, and rpms are built using this approach, they would
still be installable, even if the new process is abandonded. So there
is no flag day for revert, but some packages would effectively become
FTBFS. Any rpms which can only be built in this new scheme (e.g.
because they require older packages that the current ones in the
default build root), would have to be either fixed to build in the
normal build root, or would have to be modularized.
If this approach is abandoned, other approaches including the proposal
may be implemented, but that is only possible in the longer term.
* Contingency mechanism:
1. disable side-tag creation in koji (releng). Hopefully this would be
just a single switch somewhere. Any code that is added to koji can be
removed later (koji developers).
2. undo any documentation changes
3. adjust packages as described above (change owners, package owners).
This is very hard to say how big the scope of this would be, because
it is unclear how many packages would be involed. I think we can
assume that similarly as with Modularity, it would be <10 in the first
Fedora release where this is available.
* Contingency deadline: TBD
* Blocks release? Yes
== Documentation ==
Will be submitted by Change owners.
He / Him / His
Fedora Program Manager
The Stewardship SIG is currently providing only bare-minimum
maintenance for some packages, and none of our other packages depend
on these anymore. So, we're looking for someone to take better care of
them, preferably someone who actively uses them or maintains a package
that depends on them.
For reference, these packages directly depend on the entries in the list above:
If you received this email directly, you're a (co-)maintainer of one
of the packages listed above, and would probably be best qualified to
take care of the relevant dependency.
If you want to take any of these packages off our hands, fill out the
"package_adoption_request" template here:
If nobody claims the packages within the next two weeks, we will
orphan them again, setting them on their course towards retirement in
about two months.
Fabio (decathorpe), for the Stewardship SIG
One of the recurring themes in the ongoing Modularity threads has been that
we've made references to the problems we're trying to solve, but we haven't
done a good job of gathering those requirements and use-cases into a single
place. To resolve this, I've written a (fairly long) blog post describing
the set of problems that we are trying to solve.
You can read it with nice formatting over at
or the mediocre copy-and-paste I'm including in this message.
(Apologies for the HTML mail; I want to preserve the hyperlinks and
formatting from the blog post)
Fedora Modularity: What’s the Problem?
Much has been said
Fedora Modularity over the past couple weeks. Much of it has been
constructive; some of it the expected resistance to change that all large
features encounter. Some, however, is the result of our not having painted
a good picture of the problems that Modularity aims to solve. Numerous
suggestions have been made on the Fedora Development mailing list that
sound good on the surface but that ultimately fail to address some
important use-cases. This blog post will attempt to enumerate these cases
in detail so as to serve as a common reference point for the ongoing
Please note as well that these are goals. There are numerous places where
the implementation of Modularity at the time of this writing is not yet
fully adherent to them.
It’s all about the apps!
Though many of the readers of this blog might be of a different mind, it’s
important to remember that very few people install a Linux distribution for
its own sake. Ultimately, the goal is to “scratch a particular itch” that
the user is experiencing. The solutions may take many forms, but ultimately
this user wants to deploy some software that solves a problem for them.
This leads us to a classic problem that Linux distributions have faced: the
“Too Fast/Too Slow” problem. Linux distributions are traditionally quite
monolithic. The package collections they ship are generally
self-consistent, providing generally whatever the latest stable major
release of the software at the time of the distribution release. As the
release ages, it will receive bugfixes and enhancements, but usually will
remain on the same major version.
This is excellent for the maintainers of the distribution, because it
allows them to test that everything works together as a cohesive whole. It
means that there’s one authoritative version to align to.
Users, on the other hand, are most concerned about solving their problem.
It matters less to them that the distribution is cohesive and more that the
tools they need are available to them.
The “Too Fast/Too Slow” problem is basically this: users want a solid,
stable, reliable, *unchanging* system. They want it to stay that way for
the life of their application. However, they also want their application to
run using the set of dependencies it was designed for. If that doesn’t
happen to be the same version (newer or older) as the one selected for the
monolithic distribution, the user will now have to resort to alternative
means to get up and running. This may be as simple as bundling a dependency
or as drastic as selecting an entirely different distribution that better
fits their specific need.
A little background
One of the precursors to Fedora Modularity was Software Collections
<https://www.softwarecollections.org/> (SCLs). This was a first try at
solving the Too Fast/Too Slow” problem in the Fedora/Red Hat ecosystem.
provides two basic advantages: *Parallel Availability* and *Parallel
*Parallel Availability* means that more than one major release of a popular
software project is available for installation. For example, the “Developer
Toolset” SCLs provide access to newer versions of GCC and its related
toolchain for building software. There are Python and Ruby SCLs that
provide assorted runtimes for those languages and so on.
*Parallel Installability* means that more than one major release of a
software project can be installed on the same userspace.
A few years back, the Product Management team inside Red Hat performed a
large-scale survey of customers and potential customers about the user
experience of Red Hat Enterprise Linux. In particular, they asked about
their level of satisfaction with the software available from the enterprise
distribution and their opinion on these Software Collections.
Perhaps unsurprisingly, the overwhelming majority of respondents were
thrilled to have supported versions of software beyond what had shipped
with the base operating system. What the survey team did come away with
that was an epiphany was that the respondents generally did not care about
the parallel installability of the SCLs. For the most part, they maintained
individual userspaces (using bare metal, traditional virtualization or
containers) for each of the applications they cared about.
The most common problem reported for Software Collections was that using
them required changes to the applications they wanted to run. SCLs install
to a separate filesystem location from more traditional RPMs and
applications that rely on them need to know where to look for them. (In SCL
parlance, this is called “activating” the collection.)
The consequence of this relocation on disk is that users were unable to
take existing applications (either FOSS or proprietary) and simply use
them. Instead, they had to modify the projects to first activate the
collections. This was a consistent pain point.
Given this feedback, Red Hat came to the conclusion that parallel
installability, while nice to have, was not a critical user requirement.
Instead, the focus would be on the parallel *availability*. By dropping
this requirement, it became possible to create a solution that allowed the
different versions to be swapped in and take over the standard locations on
Meanwhile in Fedora
Of course, it’s not just Red Hat — people in Fedora are also concerned with
solving this Too Fast / Too Slow problem for our users. Efforts around this
kicked off in seriousness with the Fedora.next initiative
Fedora Project Leader Matthew Miller’s “Rings
<https://lwn.net/Articles/563395/>” talk at the first Flock conference in
This led to the proposal and approval by the Fedora Council of the Modularity
Prototype Fedora Objective
its follow-up Modularity Release Fedora Objective
Critical use cases for consumers
First and foremost, our primary driving goal is to make it easy for our
users to understand and interact with alternative software versions. In any
instance where choosing between the packager experience and the user
experience is in conflict, we elect to improve things for the user.
In order to make deployment of users’ applications simpler, we need to make
sure that software can be installed into the common, expected locations on
the system. This includes (but is not limited to):
- Libraries must be installed to /usr/lib.
- Headers must be installed to /usr/include.
- Executables must be installed to a location in the default system $PATH
- Other -devel functionality such as pkgconfig files must be installed
in their standard lookup locations.
- Installed services may own a well-known DBUS address.
- Services may own the appropriate standard TCP/UDP ports or local
*Requirement*: Installation must occur in the same locations as traditional
RPM software delivery.
Don’t break the app!
It is very common for Fedora to update to the latest major version of
packages at each new semiannual release. This ensures that Fedora remains
at the leading edge of software development, but it can wreak havoc on
anyone trying to maintain a deployment on Fedora. If they are running an
app that is built for PostgreSQL 9.6 and Fedora switches to carrying
PostgreSQL 10 in the next major release, upgrading to that release may
break their app (possibly in ways undetectable by the upgrade process).
However, staying on an old version of Fedora forever has its own problems.
Not least of these is the problem of security updates: Once a release has
been out for about 13 months, it stops receiving errata. Moreover, new
releases of the Fedora platform may have other useful enhancements (better
security defaults, increased performance thanks to compiler improvements,
*Requirement*: We need to allow users to “lock” themselves onto certain
dependencies as long as the packager is maintaining them. These
dependencies must continue to receive updates.
*Requirement*: There must be appropriate and helpful UX for dealing with
when those dependencies go EOL.
Support the developers
Developers often want to build their applications using the
latest-and-greatest version of their dependencies. However, that may not
have been released until after the most recent Fedora release. In
non-Modular Fedora, that means waiting up to six months to be able to work
on it there.
*Requirement*: It must be possible to gain access to newer software than
was available at the Fedora release GA.
Additionally, Dev/Ops people are rapidly switching to a new paradigm of
development and deployment (containers) to solve the above issue. However,
most containers today are retrieved from public repositories. The public
repositories are generally user-managed and have not been verified and
validated for security.
*Requirement*: Provide a mechanism for building *trusted* container base
and application images with content alternatives.
Keep it updated
It’s not enough that other versions of software are available to install.
They also need to be kept up to date with bug fixes and security updates.
In non-Modular Fedora, users had the ability to force DNF to lock to a
specific RPM NEVRA, but they wouldn’t get updates from it.
*Requirement*: Alternative software must receive be able to recieve and
Make it discoverable
Having alternative versions available is important but not sufficient. It
is also necessary for users to be able to locate these alternatives. Some
of our early explorations into this area failed this ease-of-use test
because they require the user to have knowledge of external sites and then
to search those sites for what they think they want.
*Requirement*: Users must be able to discover what alternative software
versions are available with tools that are shipped with the OS by default.
Ideally, these should be the same tools that they are already comfortable
Don’t break existing package management workflows
Users are slow to adapt to changes in the way they need to behave.
Requiring them to learn a new set of commands to interact with their system
will likely result in frustration and possibly exodus to other
*Requirement*: It must remain possible to continue to operate with only the
package management commands used in traditional Fedora. We may provide
additional commands to support new functionality, but we must not break the
*Requirement*: Existing automation tools such as anaconda’s kickstart and
Ansible must continue to work.
Critical use-cases for packagersDependencies
Because very little software today is wholly self-contained, it must be
possible for Modules to depend on each other.
*Requirement*: There must be a mechanism for packagers to explicitly list
dependencies on other software, including alternative versions. This
mechanism must support both build-time and run-time dependencies.
Some software is very restrictive about which dependencies it can work
with. Other software may work with several different major releases of a
dependency. For example, a user may ship two Ruby-based web applications,
one which is capable of running on Ruby 2.5 and the other that can run on
either Ruby 2.5 or Ruby 2.6. In non-modular Fedora, only one version of
Ruby would be available. If the system version was 2.5, then both
applications could run fine. But if in the next release of Fedora the Ruby
2.6 release becomes the system copy, one of those applications will have to
be dropped (or patched) to work with it.
*Requirement*: It must be possible to build software that can be run
against multiple versions of its dependencies.
*Requirement*: The packaging process for creating software that supports
multiple versions of their dependencies must not be significantly more
difficult than packaging for a single dependency.
As more and more things become modules, there is concern that such things
will grow into an unbounded matrix. For this, we need to establish policies
on when the use of alternative dependencies is preferable or when it is
better to constrain it to a single version or small set.
*Requirement*: Packaging guidelines need to provide advice on when to use
multiple alternative dependencies or to select a single one.
Managing private dependencies
When a person decides that they want Fedora to carry a particular package
and decides to do the work to accomplish this, it is not uncommon to
discover that the package they care about has additional dependencies that
are not yet packaged in Fedora. Traditionally, this has meant that the
packager has needed to package up those dependencies and then continue to
maintain them for anyone who may be using them for other purposes. This can
sometimes be a significant investment in time and energy, all to support a
package they don’t necessarily care about except for how it supports the
Sometimes, a package is needed only to build the software and is not
required at run-time. In such cases, Modularity should offer the ability to
keep those build-time dependencies entirely private and not exposed to the
Fedora Package Collection at large.
*Requirement*: Build-time only dependencies for an alternative version may
be excluded from the installable output artifacts. These excluded artifacts
may be preserved by the build-system for other purposes.
*Requirement*: All sources used for generating alternative versions,
regardless of final visibility, must be available to the community for
purposes of modification and reproducibility.
Defining the public API
Similarly, there are times when an application the packager cares about
depends on another package that is required at runtime, but sufficiently
complex that the packager would not want to maintain it for general use.
(For example, an application that links to a complicated library but only
uses a few functions.)
In this case, we want there to be a standard mechanism for the packager to
be able to indicate that some of the output artifacts are not supported for
use outside this module. If they are needed by others, they should package
it themselves and/or help maintain it in a shared place.
*Requirement*: Packagers must be able to encode whether their output
artifacts are intended for use by other projects or if they are effectively
private to the alternative version. Packagers must also have a way of
finding this information out so they understand what they can and cannot
rely on as a dependency.
Since the earliest days of Linux, the “package” has been the fundamental
unit of installable software. If you want to have some functionality on the
system, you need to learn the name of the individual packages that provide
that functionality (not all of which are named obviously). As we build
modules, one of the goals is to try to focus installation around use-cases
rather than around upstream projects. A big piece of this is that we want
to have a way to install a subset of a module that supports specific
use-cases. A common example being “server” and “client” cases.
*Requirement*: It must be possible to install a subset of artifacts from an
alternative version. These installation groups should be easily
*Recommendation*: Installation groups should be named based on the use-case
they are intended to solve. This will provide a better user experience.
Another of the major issues faced by Fedora is maintaining a release
schedule when all of the components within it follow vastly differing
schedules. There are two main aspects to this problem:
- A major version of a popular piece of software is released just after
a Fedora release, so it doesn’t land in Fedora for six months.
- Some software does frequent major revisions (Django, Node.js, etc.)
and swapping them out every six months for the latest one means that
dependent projects are constantly needing to adapt to the new breakage or
find alternative mechanisms for retaining the older, working version
- Some software does not handle multiple-version upgrades (Nextcloud,
for example). Attempting to go from version 15 to verison 19 requires first
upgrading through 16, 17, and 18.
*Requirement*: It must be possible for new alternative versions of software
to become available to the Fedora Package Collection between release dates.
*Requirement*: It must be possible for alternative versions of software to
go end-of-life during a Fedora release. This does not mean that the
software must disappear from the repositories, merely that an assertion
exists somewhere that after a certain date, the package will not receive
*Requirement*: For alternative versions whose lifecycle will continue
through at least part of the next Fedora release, it must be possible to
upgrade from one release to the next and remain with the fully-compatible
Some third-party add-on repositories (particularly EPEL) have been limited
in the past by relying on the system copies of packages in the base
distribution of the release. In the particular case of EPEL, little can be
done to upgrade these system copies. In order to be able to package much of
the available FOSS software out there, it may be necessary to override some
of the content shipped in the base system with packages known to work
*Requirement*: It must be possible for third party repositories to create
alternative versions that override base distribution content at the user’s
*Requirement*: It must be possible for third party repositories to create
alternative versions of software that exist in the base distribution.
Reduce duplication in packaging work
There is plenty of software out in the wild that maintains compatibility
over time and is therefore useful to carry in multiple releases of Fedora.
With traditional packaging, this means carrying and building separate
branches of the packages for each release of Fedora. In the case of
software “stacks” which are tightly bound, this means also manually
building each of its dependencies in each release of Fedora.
*Requirement*: It must be possible to build multiple component software
packages in the same build process.
*Requirement*: It must be possible for the packager to specify the order in
which packages must be built (and to indicate which ones can be built in
*Requirement*: It must be possible to be build for all supported platforms
using the same specification and with a single build command.
As mentioned in the Background section, the goals of Modularity are
specifically to *not* implement parallel-installability. We recommend
instead that users should rely on other mechanisms such as virtualization
or containerization to accomplish this. If parallel-installation is
unavoidable, then Modularity is not the correct tool for this job.
Arbitrary stream switching
Module streams are intended to be compatible update streams. That means
they must follow the same rules regarding RPM package-level updates within
the stream. By definition, two streams of the same module exist because
upgrades (or downgrades or cross-grades…) are not capable of being done in
a safe, automated fashion.
That does not mean that stream switching should be impossible, but it does
mean that we will not build any tools intended to handle such switching in
a generic manner. Stream switches should be handled on a module-by-module
basis and detailed instructions and/or tools written for each such case.
I incidentally discovered today that, since quite recently, there's a
Red Hat font . And this led me to think about the popularity of the
Ubuntu font, you know, and how nice would be to have a nice catchy
official Fedora font integrated into the distro... I'm just thinking
aloud, because I don't know anything about font design. But maybe
someone picks up the gauntlet... ;-)
On 25. 10. 19 19:30, Mikolaj Izdebski wrote:
> Currently default Java runtime in Fedora is OpenJDK 8. This is not the
> latest OpenJDK packaged, but still remains system-default version.
> Because of that Apache Maven and Apache Ant in Fedora are built using
> OpenJDK 8 and run on OpenJDK 8.
> I am planning to switch Maven 3.6 and Ant 1.10 modules to build with
> and run on OpenJDK 11, which is the latest LTS release of OpenJDK.
> This also means that future streams of javapackages-tools module will
> default to use OpenJDK 11 for building packages. Please let me know if
> you have any concerns.
Hello, I am not very familiar with how Java works in this regard, but since this
is the default stream etc., wouldn't it be wise to coordinate such change with a
general OpenJDK 11 default Fedora system wide change?
E.g. would the dependent OpenJDK 8 packages still build in stable releases if
this change is done globally and for example if Ursa Major/Prime/... is activated?
It's been incredible to part of this project and community! :-)
Once upon a time I was an (over?)enthusiastic packager and it's left me
with ownership of 300+ packages. O_o
In the last couple years I haven't been able to dedicate enough time to
Fedora, and I've just about kept my most important packages ticking along.
I keep thinking I'll eventually get around to everything, but I should
probably stop kidding myself! So it's time to step down and let other
people do a better job than I'm doing :-)
(Of course, I still plan to use Fedora for my servers and laptops
Unfortunately, I have an insane number of NodeJS packages (sorry!), but
here's me trying to step down in a helpful manner:
1. nginx, tor and torsocks have active co-maintainers who've been doing
a great job. Massive thanks to Felix (heffer) and Marcel (maha) in
particular! I've emailed them to see if they want ownership.
2. I have 5 packages that need owners. Volunteers welcome. [a]
3. I've removed my admin & commit access from 10 packages. These are
owned by someone else, but some may be in need of co-maintainers. [b]
4. I've removed my admin & commit access from 30 NodeJS packages. Most
are already owned by tomh so are in brilliant hands. [c]
5. I have 148 NodeJS packages that are listed as runtime dependencies by
other packages (in rawhide). These need owners and love. [d]
6. I have 7 NodeJS packages that are listed as BuildRequires by other
packages (in rawhide) but aren't runtime dependencies. These need
7. I have 75 NodeJS packages that are *not* listed as dependencies (in
rawhide) by any other package. These may need owners. [f]
8. I've sent emails to co-maintainers for 51 packages asking if they
want ownership. [g]
9. There are 39 other packages that I need to ask someone to remove my
commit access from (where I'm not admin so can't remove myself).
Hopefully that's scriptable by a Proven Packager?
After a few weeks, if there are any packages I own where nobody has
volunteered to take ownership, I'll orphan them.
[a]: Need owner
[b]: Remove my admin/commit access
[c]: Removed my admin/commit access
[d]: Need owner, listed as Requires
[e]: Need owner, listed as BuildRequires
[f]: Need owner, not listed as Requires/BuildRequires
[g]: Sent emails to co-maintainers
I've been using Fedora for a long time, but I was at lost to see there's
no beignet supported in Fedora 30. But fortunately, archlinux had
source patches for glibc-2.29, llvm,clang 8 and it worked on Fedora
30. However now on Fedora 31, archlinux's patch any longer works, and
I am obliged to use binary packages of beignet borrowed from Fedora 29.
But it's old and won't held in Fedora mirrors in the near future.
I guess there are many users still using Ivybridge or Haswell and
needing beignet. Will developers support beignet?
Thanks in advance!!
In the process of unorphaning resteasy, I picked up several other
packages necessary to keep it alive. After trimming resteasy
down, I was left with the following packages.
- classmate (cc: lef)
- cli-parser (cc: lef)
- jackson-dataformat-xml (cc: lef, dchen)
- jandex-maven-plugin (cc: lef)
- java-oauth (cc: lef)
- jboss-connector-1.6-api (cc: lef, gil)
- jboss-jaspi-1.1-api (cc: lef)
- jersey (cc: dchen, gwei3)
- mimepull (cc: lef, java-sig)
- mustache-java (cc: dchen, lef, mizdebsk)
- netty3 (cc: lef, jerboaa)
- picketbox (cc: lef, gil)
- picketbox-commons (cc: lef, gil)
- picketbox-xacml (cc: lef, gil)
- rxjava (cc: rfenkhuber)
I intend to orphan them all on Friday unless someone else
wants these packages.