Modularity and the system-upgrade path
by Stephen Gallagher
Right now, there are two conflicting requirements in Fedora Modularity
that we need to resolve.
1. Once a user has selected a stream, updates should follow that
stream and not introduce incompatiblities. Selected streams should not
be changed without direct action from the user.
2. So far as possible, Modularity should be invisible to those who
don't specifically need it. This means being able to set default
streams so that `yum install package` works for module-provided
content.
Where this becomes an issue is at system-upgrade time (moving from
Fedora 30->31 or continuously tracking Rawhide). Because of
requirement 1, we cannot automatically move users between streams, but
in the case of release upgrades we often want to move to a new default
for the distribution.
The Modularity WG has generally agreed that we want and need to
support behavior of the following use-cases:
Use Case 1:
On Fedora 30, user Alice runs
yum install Foo
The package "Foo" is provided by a module "foo" with a default stream
"v1.0". Because it's available in a default stream, the package is
installed and the module stream "foo:v1.0" is implicitly enabled for
the system.
Fedora 31 is released. On Fedora 31, the module "foo" has a new
default stream "v1.1". When upgrading from Fedora 30 to Fedora 31,
Alice expects the package Foo she installed to be upgraded to version
1.1, because that's what would have happened if it was provided as a
package from the non-modular repositories.
Use Case 2:
On Fedora 30, user Bob runs
yum enable foo:v1.0
In this case, the "v1.0" stream of the "foo" module has a dependency
on the "v2.4" stream of the "bar" module. So when enabling "foo:v1.0",
the system also implicitly enables "bar:v2.4".
Fedora 31 is released. On Fedora 31, the module stream "foo:v1.0" now
depends on "bar:v2.5" instead of "bar:v2.4". The user, caring only
about "foo:v1.0" would expect the upgrade to complete, adjusting the
dependencies as needed.
At Flock and other discussions, we've generally come up with a
solution, but it's not yet recorded anywhere. I'm sending it out for
wider input, but this is more or less the solution we intend to run
with, barring someone finding a severe flaw.
Proposed Solution:
What happens today is that once the stream is set, it is fixed and
unchangeable except by user decision. Through discussions with UX
folks, we've more or less come to the decision that the correct
behavior is as follows:
* The user's "intention" should be recorded at the time of module
enablement. Currently, module streams can exist in four states:
"available, enabled, disabled, default". We propose that there should
be two additional states (names TBD) representing implicit enablement.
The state "enabled" would be reserved for any stream that at some
point was enabled by name. For example, a user who runs `yum install
freeipa:DL1` is making a conscious choice to install the DL1 stream of
freeipa. A user who runs `yum install freeipa-client` is instead
saying "give me whatever freeipa-client is the default".
* The state `dep_enabled` would be set whenever a stream becomes
enabled because some other module stream depended on it. This state
must be entered only if the previous state was `default` or
`available`. (We don't want `enabled` or `disabled` streams being able
to transition to this state.)
* The state `default_enabled` would be set whenever a stream becomes
enabled because a transaction pulled in a package from a default
stream, causing it to be enabled. This state must only be entered if
the previous state was `default` or `dep_enabled`. We don't want
`enabled` or `disabled` to be able to transition to `default_enabled`.
If a user requests installation of a package provided by a stream
currently in the `dep_enabled` state, that stream should transition to
the `default_enabled` state (meaning that now the user would expect it
to be treated the same as any other default-enabled stream).
* When running `dnf update`, if a module stream's dependency on
another module changes to another stream, the transaction should cause
that new stream to be enabled (replacing the current stream) if it is
in the `dep_enabled` state.
When running `dnf update` or `dnf system-upgrade`, if the default
stream for a module installed on the system changes and the module's
current state is `default_enabled`, then the transaction should cause
the new default stream to be enabled.
* If stream switching during an update or upgrade would result in
other module dependency issues, that MUST be reported and returned to
the user.
This requires some constraints to be placed on default and dependency changes:
* Any stream upgrade such as this must guarantee that any artifacts of
the stream that is exposed as "API" MUST support RPM-level package
upgrades from any previous stream in this stable release. (Example:
"freeipa:DL"1 depends on a the "pki-core:3.8" stream at Fedora 30
launch. Later updates move this to depending on "pki-core:3.9" and
even later "pki-core:3.10". In this case the packages from
"pki-core:3.10" must have a safe upgrade path from both "pki-core:3.8"
and "pki-core:3.9" since we cannot guarantee or force our users to
update regularly and they might miss some of the intermediate ones.
4 years, 5 months
Introducing Square 1
by Troy Dawson
I would like to introduce a plan I call Square 1 [1][2]
There are two goals to Square 1.
The first is to get, and keep, the core buildroot[3] packages, self-hosting[4].
The second is to get the list of core buildroot packages as small as possible.
What are the benefits to Square 1?
More stable release and less failed builds.
If we are able to shrink binaries, faster koji builds.
Smoother initial creation of RHEL 9.[5]
What are the milestones to get these benefits?
- Get initial list of "core binaries"
- write/find software that will find binary/source dependencies
- write/find software that will track binary/source dependencies
- write/find/setup automation that finds and tracks binary/source
dependencies, so people can easily see what has changed over time.
- work with package maintainers to trim down binary/source dependencies
-- trimming out "extra" package languages. (ex: perl for a
minor script, when everything is in python.)
-- trimming functionality and/or moving functionality to sub-packages
or separate package.
- integrate these tests into the rawhide gating system, to alert when
new dependencies have been added.
Much of this work overlaps with the Fedora Minimization efforts.[6]
Square 1 hopes to utilize, rather than duplicate, their efforts. And
maybe some tools created for Square 1 can help the minimization
efforts.
Thoughts?
Ideas?
Comments?
Troy Dawson
[1] - Square 1 is at the heart of Ring Zero
[2] - This has nothing to do with the company or software with a
similar sounding name.
[3] - The core buildroot is the packages in @buildsys-build, and
everything needed to build those packages.
[4] - self-hosting is the ability to build all the packages on themselves.
[5] - Yep, I said it. We're already looking at RHEL 9.
[6] - https://docs.fedoraproject.org/en-US/minimization/
4 years, 5 months
libdav1d SONAME bump
by Robert-André Mauchin
Hello,
Dav1d 0.5.0 was published today and brings a SONAME bump from libdav1d.so.
2.0.0 to libdav1d.so.3.0.0.
I will be updating it next week on F31/32, consumers of these libraries
(ffmpeg, xine-lib, vlc) will need to rebuild their packages.
Best regards,
Robert-André
4 years, 5 months
Backend storage clean-up
by Jakub Kadlcik
Hello,
we have decided that it is a time to go through Copr backend data and
clean it up a little. Due to several bugs forgetting to remove backend
data after removing their records from the database, _temporarily_
backing up some folder here and there, etc, we ended up with a lot of
unknown data, that should have been already deleted.
So, we wrote a script [1] to find data that should be deleted, and we
... haven't deleted it yet. Instead, we put it aside in a case there
were any false-positives by the script. If you want to be extra safe,
I am attaching a list of all of those files, you may check it.
If you find out, that we accidentally want to remove any of your data
that is still being used, please contact us immediately! Otherwise, we
are going to delete it once we are running out of disk space (which
may not take a lot of time)
[1] https://pagure.io/copr/copr/blob/master/f/backend/run/copr_print_results_...
Thank you for understanding,
Jakub
4 years, 5 months
Fedora 32 System-Wide Change proposal: Modules in Non-Modular Buildroot
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
Enable module default streams in the buildroot repository for modular
and non-modular RPMs.
== Summary ==
This Change (colloquially referred to as "Ursa Prime") enables the
Koji build-system to include the RPM artifacts provided by module
default streams in the buildroot when building non-modular (or
"traditional") RPMs.
== Owner ==
* Name: [[User:Sgallagh| Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
* Responsible WG: Modularity WG
== Detailed Description ==
As a major part of the Modularity design, we have a concept of default
module streams. These streams are built as modules, but the RPM
artifacts they deliver are intended to be used just like non-modular
RPMS. The aspirational goal is that a user of the system who never
executes a module-specific command (such as `dnf module install
nodejs:8`) should experience no meaningful changes in behavior from
how they would interact with a completely non-modular system. In
practice, this may mean that the informational output of package
managers may indicate that modules are being enabled and used, but a
user that does not have a specific reason to interact with the
selection of a module stream should have that managed on their behalf.
Similarly, the experience for package maintainers of non-modular
packages should be unaffected by an RPM dependency moving from the
non-modular repository into a default module stream. Up to the
present, this has not been the case; no module stream content has been
available in the non-modular buildroot for other packages to consume.
Koji builds of non-modular RPMs have had only the other non-modular
RPMs from that release available to their buildroots. In contrast,
building on local systems has access to both the non-modular RPMs and
the RPMs from any of the default module streams. With this Change,
Koji builds will have the same behavior and be able to depend on
content provided by default module streams. It also enables the same
behavior for Modular builds: the `platform` stream will now include
the contents of the default module streams for each release and do not
need to be explicitly specified in the modulemd `buildrequires`.
Note: This Change does not address the other major Modularity issue we
are facing around distribution upgrades with differing default
streams. When discussing this Change, please keep that topic separate.
== Benefit to Fedora ==
This will simplify the lives of package maintainers in Fedora in two
primary ways. I'll use a hypothetical example of the Node.js
interpreter and a JSApp package which is capable of running on Node.js
10 or 12 (but requires newer features than are provided by Node.js 8).
Additionally, the JSApp package requires the same versions of Node.js
at build-time.
* Fedora 29 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 30 ships `nodejs:8`, `nodejs:10` and `nodejs:12` module
streams. The `nodejs:10` stream is set as the default stream.
* Fedora 31 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F31 lifetime.
* Fedora 32 ships `nodejs:10` and `nodejs:12` module streams. The
`nodejs:12` stream is set as the default stream. The `nodejs:14`
stream will likely become available during the F32 lifetime.
On Fedora 29 through 31, the Node.js package maintainer needs to build
the `nodejs:10` package both as a module and as a non-modular RPM in
the distribution so that the JSApp package can be built. With this
Change, the Node.js package maintainer in Fedora 32+ will only need to
build the various Node.js streams and make one of them the default
stream. The packages from it will then be added to the buildroot for
non-modular packages. This will also make the packaging process
somewhat more efficient, as the maintainer needs only to manage the
module stream and the MBS will build it for all configured platforms.
Similarly, from the perspective of dependent maintainers, there will
no longer be anxiety about needing to move their package to a module
if one or more of their dependencies drops their non-modular version
in favor of a default stream. Their builds will continue to work as
they do today.
== Scope ==
* Proposal owners:
# Update Packaging Guidelines with
[https://pagure.io/modularity/issue/146#comment-600328 requirements]
for module default streams
# Create a Pungi configuration to generate the buildroot from the
default module streams.
# Include `default_modules_scm_url` in the platform virtual module specification
# Configure Koji tags for inheriting the new modular-defaults
buildroot into the standard buildroot
* Other developers:
Packagers of default module streams will be required to conform to the
[https://pagure.io/modularity/issue/146#comment-600328 policy]
regarding visibility of stream artifacts. Any default module stream
that is not in compliance by one week before Beta Freeze will cease to
be a default stream.
* Release engineering:
# https://pagure.io/releng/issue/8879 - Create pungi config for
Rawhide/F32 ursa prime buildroot
# https://pagure.io/releng/issue/8880 - Include
`default_modules_scm_url` in platform 31 virtual module
# https://pagure.io/releng/issue/8881 - Configure Koji tags for
inheriting f32-modular-buildroot
* Policies and guidelines:
The Modularity Packaging Guidelines will need to be updated to
indicate the strict requirements on default streams.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This change is on the build-system side of things and should not
impact the upgrade process directly.
== How To Test ==
# Build a modular stream
# Make that stream a default stream (or a buildroot override)
# Build a non-modular RPM that requires an artifact RPM from the modular stream.
== User Experience ==
This should not change the end-user experience.
== Dependencies ==
Nothing known that isn't listed in the scope.
== Contingency Plan ==
* Contingency mechanism: Disable the buildroot inheritance in Koji to
revert to the current behavior.
* Blocks release? Ambiguous: lack of complete implementation may
indirectly cause blocking issues.
* Blocks product? No
== Documentation ==
== Release Notes ==
None needed, the Change is not user-facing.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 5 months
Add a rule to have a compose when Fedora branched
by jkonecny＠redhat.com
Hello everyone,
I'm Anaconda developer and I'm also taking care about our
infrastructure and this Fedora release brought me a plenty of
"unnecessary" work thanks to the fact that compose for Fedora 31 was
not available until a week before beta freeze. That is too late.
I wasn't the only one who had these problems, copr had issues for
Fedora 31 and couldn't enable chroot so they had to do changes to
correct these broken things. And I'm not talking about Fedora QA team
which couldn't test almost anything before beta freeze.
The problem is that when we don't have a compose we don't have packages
for testing and then more and more changes are getting in but we are
not able to check if they are working. If we don't have packages the
mock can't properly work and you are not able to do a system upgrade.
The only test point is compose but that is just a small portion. Not
being able to test Fedora for a few weeks is situation which should not
happen.
To make things even worse there was a switch to python 3.8 on Rawhide
which wasn't really prepared (pylint did not worked). So for a few days
we were with broken Fedora 31 and Rawhide too, so most of our tests
were not working. I would really said that we were programming in the
dark. No tests, no check that changes are working. It took me almost a
week to make everything working again not talking about time spend
waiting for the compose to be available.
I want to ask for an improvement here. Ideal solution for me would be
to add rule that there have to be compose to do the branching and if
the compose fails then the branching won't happen. Not sure if this is
doable or how hard it would be to implement a similar rule, however, it
would be an ultimate solution. Then, the compose blocker bugs had to be
solved on Rawhide where they should be solved.
Please tell me what should I do next. Should I file a FESCO ticket to
add this rule?
Best Regards,
Jirka
4 years, 5 months
Fedora 32 System-Wide Change proposal: On-demand Side Tags
by Ben Cotton
https://fedoraproject.org/wiki/Changes/OnDemandSideTags
see also: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.o...
= 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.
fNN-updates-candidate).
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]]
* Email:
== 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
Modularity.
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
Requires/Recommends/Provides/Suggests/Conflicts.
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
change.
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
https://bugzilla.redhat.com/show_bug.cgi?id=1747408.
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
dependencies.
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
packages easier.
=== 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
Fedora versions.
(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
f31-updates-candidate.
=== 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
Provides:bundled(python3-qt5)=5.12.
=== 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
created manually.
== 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
in https://fedoraproject.org/wiki/Changes/Modules_In_Non-Modular_Buildroot
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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
4 years, 5 months
Some Java packages looking for new maintainer(s)
by Fabio Valentini
Hello packagers,
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.
- ed25519-java
- hibernate-jpa-2.0-api
- jackson
- jandex
- jboss-jsp-2.3-api
- jboss-transaction-1.1-api
For reference, these packages directly depend on the entries in the list above:
ed25519-java:
- eclipse-jgit
- jgit
hibernate-jpa-2.0-api:
- openjpa
jackson:
- cassandra
- openstack-java-sdk
jandex:
- hibernate
- jandex-maven-plugin
jboss-jsp-2.3-api:
- jboss-jsf-2.2-api
- jboss-jstl-1.2-api
- struts
jboss-transaction-1.1-api:
- jboss-connector-1.6-api
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:
https://www.pagure.io/stewardship-sig/new_issue
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.
Thanks,
Fabio (decathorpe), for the Stewardship SIG
4 years, 5 months
Use immutable CRAN URLs
by Iñaki Ucar
Hi,
Currently, most of the R packages included in Fedora use the following
lines in the SPEC:
URL: https://cran.r-project.org/web/packages/%{packname}/
Source0: https://cran.r-project.org/src/contrib/%{packname}_%{version}.tar.gz
This URL format is not recommended by CRAN, but more importantly, the
Source0 format does not work anymore, as [1] noted, when a new version
is released. However, there is an immutable format available, as [2]
pointed out. So my proposal is to use always the following lines
instead:
URL: https://cran.r-project.org/package=%{packname}
Source0: %{url}&version=%{version}
which are both shorter and immutable, and I propose to add this to the
R packaging guidelines too.
If we agree on this, is there any easy way to request a system-wide
change like that to all existing packages?
Regards,
--
Iñaki Ucar
[1] https://stat.ethz.ch/pipermail/r-devel/2018-October/076988.html
[2] https://stat.ethz.ch/pipermail/r-devel/2018-October/076989.html
4 years, 5 months
