Good Morning Everyone,
A little while ago[1], we integrated anitya in dist-git itself, allowing to
stop using fedora-scm-request's[2] git repository to store this information.
However, this git repository is still being used to store bugzilla overrides
(i.e.: default assignee on bugzilla ticket when they differ from the point of
contact (main admin) of the package in dist-git).
Together with Karsten Hopp we worked on integrating this functionality on
pagure-dist-git[3], thus allowing to get rid entirely of the git repository at
fedora-scm-request[2].
This work has been deployed in staging today. We would very much appreciate if
you could take a few minute of your time and see if it works to your
liking: https://src.stg.fedoraproject.org/
The overrides information from production has been migrated yesterday to the
staging dist-git, so what you see in the UI reflects the current state of the
overrides in production as of yesterday.
Here is an example with an override:
https://src.stg.fedoraproject.org/rpms/0ad
One note: in the rpms namespace, the UI will always show you the default
assignee for Fedora and Fedora EPEL, regardless of whether the package is in
EPEL.
This is a shortcoming we are aware of and will be looking at fixing in the near
future but potentially after it has reached production.
Thank you for your understanding and help testing this,
Pierre
[1] https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
[2] https://pagure.io/releng/fedora-scm-requests
[3] https://pagure.io/pagure-dist-git/
It's that time of year again... as our RPM change proposals passed with
flying colors in yesterdays meeting, I'll hope to land RPM 4.16 alpha in
rawhide later today or tomorrow by latest.
There aren't any big incompatibility bumps here, but to pave way for the
fancy new expression stuff, some dusty corners needed, well, dusting.
One of the discoveries was that rpm has accidentally long allowed
unquoted text to be used as a string in expressions. That is no longer
supported, you need to quote any strings in expressions.
Based on rpm-specs-latest.tar.xz from this morning, there are thirtysome
packages relying on this behavior, which will need fixing to be
buildable with 4.16. You'll get an error message pointing to the right
direction, eg:
error: bare words are no longer supported, please use "...": python3 ==
python3
error: ^
error: airnef.spec:83: bad %if condition: python3 == python3
This is caused by the following line in that spec:
%if %python == python3
Just add double quotes to both sides and it'll work. This is backwards
compatible so you're not breaking anything by doing so, like mentioned
above this only ever worked by accident to begin with.
Other than that, there are a couple of things that might be of
particular interest to Fedora packagers: new expression features [1] (in
spec %if and macros) including but not limited to ternary operator (eg
%[1==0?"yes":"no"]) and parametric macro generators [2] for lightning
fast dependency generation. Oh, and dependency generators can now
optionally use MIME type instead of "file" magic string for file
classification.
Last but certainly not least, please do test the database stuff! We will
not be changing the default until several weeks from now (for
stabilization and coordination with infrastructure/rel-eng efforts), but
you can and should test locally:
# echo '%_db_backend sqlite' > /etc/rpm/macros.db
# rpmdb --rebuilddb
After that you'll be using sqlite rpmdb, and you shouldn't really notice
anything at all. Except that it's typically a little faster, and should
survive abuse in ways that BDB never did.
And as usual, please report anything odd.
[1] https://rpm.org/wiki/Releases/4.16.0 has some examples, more to follow
[2]
https://rpm.org/user_doc/dependency_generators#parametric-macro-generators-…
- Panu -
https://fedoraproject.org/wiki/Changes/Module_Obsoletes_and_EOL
== Summary ==
Fix Fedora upgradability issues when upgrading systems with module
streams enabled.
== Owner ==
* Name: [[User:dmach| Daniel Mach]]
* Email: dmach(a)redhat.com
== Detailed Description ==
DNF currently doesn't have sufficient information to perform system
upgrades of systems with enabled module streams correctly.
To solve upgradability problems, we will add additional modulemd metadata.
This includes information about a stream obsoleting another one or a
stream being EOLed.
Use Cases:
* A module (all its streams) is removed from a distribution.
* A stream has reached its EOL and must no longer be available.
** The stream packages have no replacements and must be removed from
the system (an extension of fedora-obsolete-packages?)
** The stream packages get replaced with non-modular packages
* A stream has reached its EOL and is Obsoleted by another stream.
* A stream has reached its EOL and a user wants to continue using it
regardless of EOL/Obsoletes.
* A stream has reached its EOL and a user wants to install a new host
with the EOLed stream enabled.
There is going to be a new DNF config option:
* (name: TBD) - automatically follow stream EOL/Obsoletes; only print
a warning if turned off
Proposed new modulemd document:
<pre>
document: TBD
version: 1
data:
# A string representing UTC date in ISO 8601 format: YYYY-MM-DD[T ]HH:MMZ
# When merging, entries with a newer 'modified' value will override
any earlier values.
# MANDATORY
modified: 2020-03-19T23:26Z
# A boolean option to cancel/reset all previously specified obsoletes
# Example: repo 'fedora' has Obsoletes:nodejs:12; we want to bring
nodejs:12 back in 'updates'
# If used, following options will be ignored: eol_date, obsoleted_by
# OPTIONAL
<TBD>: <bool>
# A string representing a Name of a module that is EOLed
# MANDATORY
module: nodejs
# A string representing a Stream of a module that is EOLed
# MANDATORY
stream: 11
# A string representing a Context of a module that is EOLed
# If not specified, all contexts get EOLed.
# NOTE: consider specifying a list of contexts
# OPTIONAL
context: aabbccddee
# A string representing UTC date in ISO 8601 format: YYYY-MM-DD[T ]HH:MMZ
# It is strongly recommended to keep HH:MM to 00:00.
# If not specified, the module is EOLed immediately.
OPTIONAL
eol_date: 2020-03-19T00:00Z
# A string describing the change, reason, etc.
# MANDATORY
message: "Module stream nodejs:11 is no longer supported. It is
recommended to switch to nodejs:12"
# If a stream is not EOLed but Obsoleted, provide details about the
obsoleting stream:
# OPTIONAL
obsoleted_by:
module: nodejs
stream: 12
</pre>
== Benefit to Fedora ==
Seamless system upgrades of systems with module streams enabled.
== Scope ==
* Proposal owners:
** Introduce modularity features to:
** Obsolete a module stream
** Stream EOL
** Design a new modulemd documents for Obsoletes and EOL
** Get the new documents supported by libmodulemd
** Implement the new functionality in the DNF stack (libdnf, dnf,
microdnf) and PackageKit
* Other developers:
** Follow updated packaging policy. See the "Policies and guidelines" section.
* Release engineering: [https://pagure.io/releng/issue/9359] (a check
of an impact with Release Engineering is needed) <!-- REQUIRED FOR
SYSTEM WIDE CHANGES -->
Maintain and distribute new module metadata.
* Policies and guidelines:
** Packaging policy and modularity documents require a change:
*** When a module stream gets removed from a Fedora release, the
maintainer of the module stream must provide a modulemd document with
Obsoletes or EOL data.
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
This feature solves upgradability problems of systems with module
streams enabled.
== How To Test ==
Stream Obsoletes:
* Enable a stream that is not available in the next version of Fedora
and is obsoleted by another stream in the metadata
* Run system upgrade
* Verify that the obsoleting stream is enabled instead of the obsoleted one
Stream EOL:
* Enable a stream that is not available in the next version of Fedora
and is obsoleted in its module metadata
* Run system upgrade
* Verify that the EOLed stream is no longer enabled and does not show
up in `dnf module list`
Fedora upgradability:
* Install Fedora 31 or 32
* For each $stream in available streams
** dnf module reset '*'
** dnf module enable $stream
** dnf distro-sync --releasever=33 --assumeno
** # the command must not throw any errors related to modularity,
especially related to the enabled stream
== User Experience ==
Fedora users experience upgradability problems when upgrading to Fedora 32
when they have any module streams enabled.
If a stream no longer exists on the version of Fedora they are upgrading to,
DNF used to error out on resolving modular dependencies which was a
clear release blocker.
To workaround this case, all module streams are reset during the system upgrade.
By doing this, modularity users lose information about enabled streams
and they need to re-enable them by hand.
This Change aims at removing the upgradability problems and allowing
Fedora modularity users
to upgrade their systems while keeping their streams enabled, reset or
switched (obsoleted)
according to newly provided modular metadata.
== Dependencies ==
* libmodulemd
* libdnf
* dnf
* microdnf
* PackageKit
== Contingency Plan ==
* Contingency mechanism: Remove the new metadata from Fedora composes
and repositories. Fedora will stay at the current behavior.
* Contingency deadline: Beta Freeze
* Blocks release? Yes
== Documentation ==
TBD
== Release Notes ==
Modularity supports Obsoleting streams and stream EOL (end-of-life).
Enabled streams are no longer reset during the system upgrade.
When a stream reaches its EOL, it's reset.
When a stream is Obsoleted, it's switched to the obsoleting stream.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Libdb_deprecated
== Summary ==
This change should inform maintainers and developers about effort to
remove libdb in future.
== Owner ==
* Name: [[User:fjanus|Filip Januš]]
* Email: fjanus(a)redhat.com
== Detailed Description ==
We would like to remove libdb from Fedora in future, because
BerkeleyDB 6.x has a more restrictive license than the previous
versions (AGPLv3 vs. LGPLv2) and due many projects can't use it.
Nowadays Fedora uses the old version (5.3.28) and we can't update to
newer. Due to many projects have libdb dependency, we propose few
steps to complete removal. First step would mark libdb as deprecated
package in Fedora 33. Next steps in Fedora 35 would provide converting
tool for existing databases and mark libdb as orphaned.
== Benefit to Fedora ==
We would like to have most recent releases of components in Fedora,
which are supported by upstreams. But due to licence of BerkeleyDB we
need to hold old BerkeleyDB version in Fedora.
== Scope ==
* Proposal owners: Not needed for this change - only deprecation
* Other developers: Developers should prepare own projects(scripts,
programs, packages, ...) for the next change and for the complete
libdb removal.
* Policies and guidelines: Not needed for this change - only deprecation
* Trademark approval: Not needed for this change - only deprecation
== Upgrade/compatibility impact ==
This change hasn't direct impact onto actual dependencies. Purpose of
this change is inform and prepare people to future change which will
affect many components.
[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
Here] is short discussion from Fedora-devel list.
== User Experience ==
There is no change for users. Package is marked only as deprecated
package and behaves as before.
== Dependencies ==
*Libdb has many dependencies:
*389-ds-base
*apr-util-bdb
*bind-sdb
*bogofilter
*cld
*clisp
*cyrus-sasl-lib
*dsniff
*evolution-data-server
*exim
*heimdal
*iproute
*ipv6calc
*isync
*jabberd
*jigdo
*jigdo-gui
*kdesvn
*libetpan
*libopendkim
*libserf
*lizardfs-master
*mesos
*mod_dav_svn
*mod_perl
*mod_qos
*mod_security
*netatalk
*nmh
*nss_updatedb
*nvi
*opendkim
*openldap-servers
*opensips-db_berkeley
*opensmtpd
*pam
*pam_abl
*pam_ccreds
*perdition
*perl-BDB
*perl-BerkeleyDB
*perl-DB_File
*perl-eperl
*php-dba
*pl
*postfix
*python3-bsddb3
*rapidsvn
*redland
*reprepro
*rpm
*rsvndump
*sendmail
*sks
*spamprobe
*squid
*squidGuard
*subversion
*tqsllib
*trustedqsl
*webalizer
*xemacs
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A
* Blocks release? No
== Documentation ==
There is no upstream documentation, but
[[User:Pkubat/Draft_-_Removing_BerkeleyDB_from_Fedora|here]] is a list
of dependencies with some useful comments and
[[User:Pkubat/BerkeleyDB_alternatives|here]] some possible
alternatives.
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
https://fedoraproject.org/wiki/Changes/Java11 .
== Summary ==
Update the system JDK in Fedora from java-1.8.0-openjdk to java-11-openjdk.
== Owner ==
* Name: [[User:jvanek| Jiri Vanek]]
* Email: <jvanek(a)redhat.com>
* Product: java and java stack
* Responsible WG: java-sig (java and java-maint)
== Detailed Description ==
Fedora currently ships:
* java-1.8.0-openjdk (LTS)
* java-11-openjdk (LTS)
* an java-latest-openjdk (on jdk14, STS).
where the version-less '''java''' and '''javac''' (and friends) are
provided by java-1.8.0-openjdk.
So every package honoring the packaging rules and requiring java ,
java-headless or java-devel is built in brew by
java-1.8.0-openjdk-devel and pulls java-1.8.0-openjdk(-headless) in
runtime (See [https://fedoraproject.org/wiki/Java java] ). Also
javapackaging-tools are using java-1.8.0-openjdk as hardcoded runtime
(see [https://fedoraproject.org/wiki/Changes/Decouple_system_java_setting_from_ja…
changes])
Debian already moved to JDK11 as system JDK, and in Fedora community
we can hear for last two years increasing voices for jdk11 to become
the system one. And apparently the java stack is really quite ready
for JDK11. Fedora is considered to be bleeding edge distribution, so
we should move forward, however JDK11 is not 100% compatible with
JDK8, so there may rise nasty issues and very unhappy users.
Major incompatibility is in encapsulation. What was private, is now
really private and if one was using it (and it was common) then the
code will stop working. Unluckily, most of those issues are not only
build time issues, but runtime issues, so hard to spot without proper
test coverage.
=== A bit of history to recall: ===
version (upstream support) - fedora state
* Java SE 6 (LTS 2006-cca2014) - added as techpreview in F8 replaced
GCJ around F13. See https://fedoraproject.org/wiki/Releases
* Java SE 7 (LTS 2011-2020(?)) - entered Fedora as tech preview
around F16/17 replaced JDK 6 as System JDK in F17
* Java SE 8 (LTS 2014-2026(???)) - entered Fedora as tech preview in
F19 replaced JDK 7 as System JDK in F21. JDK6 and JDK7 later returned
as community driven java-1-{6,7}-0-openjdk-legacy packages for a while
* Java SE 9 (2017-2018) - entered Fedora around F26 as secondary,
java-1.9.0-openjdk alongside java-1.8.0-openjdk
* Java SE 10 (2018-2019) - entered F28 as secondary,
java-latest-openjdk alongside java-1.8.0-openjdk
* Java SE 11 (LTS 2018-??) - entered Fedora as tech preview in F29
together with java-latest-openjdk and java-1.8.0-openjdk
* Java SE 12 (2019) - updated java-latest-openjdk transparently and
keept going alongside java-1.8.0-openjdk and alongside
java-11-openjdk
* Java SE 13 (2019-2020) - updated java-latest-openjdk transparently
and keept going alongside java-1.8.0-openjdk and alongside
java-11-openjdk
* Java SE 14 (March 2020-2021(?)) - is updating java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 15 (2020(?)-2021(?)) - will update java-latest-openjdk
transparently and will continue to live next to any system JDK(s)
* Java SE 16 () - will update java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* Java SE 17 (LTS) - will very likely update java-latest-openjdk
transparently and will become future system JDK java-17-openjdk some
year later
* Java SE 18 () - will update java-latest-openjdk transparently and
will continue to live next to any system JDK(s)
* ....
=== "Political disclaimer" ===
In previous bumps, we, Red Hat's openjdk team, were a driving force to
bump the system JDK. In this case, we are a bit reluctant, but the
desire from users to bump the JDK seems strong. We are quite happy to
skip JDK11 as system JDK at all, and jump directly from 8 to 17 in
some three years.
== Benefit to Fedora ==
JDK11 is out for some time, and most of the bleeding edge
distributions already make it default. Most of the projects already
adapted new features and make necessary forward-compatible chnages.
Although we can can expect some family of packages to remain on jdk8
for ever, [https://en.wikiquote.org/wiki/Dune_(film) the spice should
flow]
== Scope ==
=== keep java-1.8-0-openjdk but remove its java/javac versionless
provides, make java-11-openjdk providing java, javac and other
versionless provides ===
* will guarantee fedora to be pure JDK11 distro.
* will allow maintainers of JDK9 or up incompatible packages to keep
using JDK8, however this is just false hope.
** if such an package depends on package build by JDK11, JDK8 will not
be able to pick up that dependency.
** this may lead to quite a lot of bundling or compat. packages, but
may be acceptable
** people developing JDK8 applications will very likely stay with fedora:)
While quite a lot of users will rejoice, there may be cases where
application is very hard to migrate to JDK11, so the contingency plan
should be taken very serious.
=== Other possible approaches already discarded by various discussions ===
(see wiki page)
=== Other ===
* Proposal owners:
** based on above, adapt jdk8 and jdk11 package provides
** If necessary tune the build environment
* Other developers:
** based on selected approach to tune the main build tools
*** at least jpackage-tools and maven will be very likely affected
** based on selected approach to tune the rpmbuild/macros
** many java package maintainers will maybe need to adapt theirs packages
*** After the approach is agreed, mass rebuild must be performed
*** FTBFS bugs connected with this proposal, maybe with jira ticket to
allow discussion.
*** Solutions to most common errors should be gathered and published
* Release engineering: [https://pagure.io/releng/issue/9347 9347]
** mass rebuild will be required for this change
* Policies and guidelines: how to deal with build failures, eventually
how to use some jdk11 specific build features will be provided
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Once the change is implemented properly, the update should be flawless
and seamless
== How To Test ==
* Depends on selected approach, only JRE11 should remain the only
system JDK after installing base javastack on clean system
* Both jdk8 and jdk11 can live togehter on system
* jdk11 will be selected by default and will run most of the base java stack
* todo, add few java-package to isntall examples, hopefully for jdk11 only
== User Experience ==
* Standard user should be still be able to use java stack without even
noticing the chnage.
* Standard developer should be still be able developer any java
application comfortably
* Standard packager will not suffer to much, and should be able to
pack any java application for fedora
== Dependencies ==
Around 2600 packages will need attendance
$ repoquery -q --whatrequires java-headless |wc -l
2481
$ repoquery -q --whatrequires java | wc -l
78
$ repoquery -q --whatrequires java-devel | wc -l
21
Packages needing major work will be
* java-1.8.0-openjdk
* java-11-openjdk
* icedtea-web
== Contingency Plan ==
* If the mass rebuild, after the change application, breaks to much
packages, or some important will be unfixable, jdk8 must be restored
back to the position of system jdk.
* Contingency mechanism: Return jdk8 as system jdk and mass rebuild
again. Note, that this may be very hard, because during build of
packages by jdk8, by jdk11 built dependencies will be picekd up, so
build will fail. Maybe several iterations of mass rebuild will be
needed.
* Contingency deadline: beta freeze
* Blocks release? Yes
* Blocks product? N/A
* Generally going back will be imho impossible. Once the decision is
taken, javastack should be fixed, and where it can not be fixed, it
had to migrate to compact packages, or bundled-dependencies pacages or
be orphaned.
== Documentation ==
* oracle11 release notes:
https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.ht…
* openjdk11 jeps: https://openjdk.java.net/projects/jdk/11/
* As we are moving from java8 to 11, and jdk9 is what brought in
breaking changes, providing also 9 and 10:
** openjd10 https://openjdk.java.net/projects/jdk/10/
** openjd9 https://openjdk.java.net/projects/jdk9/
** oracle10 https://www.oracle.com/technetwork/java/javase/10-relnotes-4108314.html
** oracle9 https://www.oracle.com/technetwork/java/javase/9-relnotes-3622618.html
*** where jdk9 migration
https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-7744EF96-5899-4…
is quite useful for this proposal
* todo, gather most common issues packagers can face and provide solutions
** :
** :
--
Ben Cotton
He / Him / His
Senior Program Manager, Fedora & CentOS Stream
Red Hat
TZ=America/Indiana/Indianapolis
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
There has been a lot of (really good!) discussion on the original
proposal thread, but as it has grown too large to follow anymore, I'm
restarting it. I have made numerous changes to the Change Proposal
page to improve the scope of the proposal as well as clarify some of
the questions that have come up repeatedly in the original thread.
Please see the newly-updated
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
for more details[1].
== Summary ==
ELN is a new buildroot and compose process for Fedora that will take
Fedora Rawhide dist-git sources and emulate a Red Hat Enterprise Linux
compose. Feedback from this build, compose and integration testing
will be provided to Fedora packagers so that they can see the
potential impact of their changes on RHEL development.
== Owner ==
* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha(a)bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
[1] List of changes between the original and new versions:
https://fedoraproject.org/w/index.php?title=Changes%2FELN_Buildroot_and_Com…
-----BEGIN PGP SIGNATURE-----
iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAl5+FpgACgkQRduFpWgo
bRE90QwAu8gIRcPcyct73D2jF+MBzmy7XFdlilLIcL4Z3RWINKgHcNUTw+jC9n3K
jJdBMOUji1DAD+fw1UeuJ+x0ThMCg1zqYgRDalYE/7AiRWxjD73rQ5V3q7EKLycJ
6Al+n3rB+P5vy+TB9m/mB223hjmUxv5+FXEqmkNcpvZiRsTqIk5Ss+22zSoFhs8D
6DJE6yPTPiNiygJZBIgE508pXakHsl2CCpKNccHEpj5eNU0t93kbb7oWVJXf6i6Z
Y09jvZLO4mVcn1vUIJRtpFJvNWbzIEIGyFuELgvHoVT66xSe4MwxvW0A6ChIwngQ
mvNM43Ild6Lq29+qtVCje6fovh3yPzRWitoEwdClg4HOj5C2wymeQWO01a/ydQNg
lUwmNnFHPZ4/2TtHWw64QkKdm9QP6bfmdMYJOy+iKhibmUiws4WheTB5L6zyh4ED
pvLLszQvReqDj5N56Oghr5YquRdQLIACEfqm5s4A/iipwDEj3WY5niHzAt0jBz1q
6DnLPiZt
=42JI
-----END PGP SIGNATURE-----
As Ben is on PTO, I'd like to present the System-Wide Change
https://fedoraproject.org/wiki/Changes/ELN_Buildroot_and_Compose
== Summary ==
The goal of the ELN project is to continuously build Fedora Rawhide
packages and composes in the way which resembles the CentOS and RHEL
build process and to provide a feedback loop for Fedora maintainers on
the status of those builds.
== Owner ==
* Name: [[User:Bookwar| Aleksandra Fedorova]]
* Email: alpha(a)bookwar.info
* Name: [[User:Sgallagh | Stephen Gallagher]]
* Email: sgallagh(a)redhat.com
== Detailed Description ==
This Change supersedes the previously-approved [[Changes/Additional
buildroot to test x86-64 micro-architecture update|Change]] to enable
an additional buildroot. During development, its scope has expanded to
include the entire process of how the Fedora sources are built and
composed into shippable artifacts.
ELN is an evolution of the request for an alternate buildroot for
newer x86_64 processors. The reasoning behind that new buildroot was
that we expected that the next major release of RHEL would likely drop
support for older hardware and therefore could take advantage of
enhancements and processor extensions available for newer hardware. As
plans for this proceeded, they expanded into a desire to do more than
just test out the processor architecture. Instead, we want to have a
complete alternative compose of Fedora Rawhide that resembles the way
that Red Hat and CentOS builds their packages. The idea being that
Fedora developers and third-party vendors who rely on Red Hat
Enterprise Linux have a place where they can directly contribute to
what will eventually become the next RHEL.
ELN (Enterprise Linux Next) is going to be that place. What we want to
do is establish a set of RPM conditionals that can be used for the set
of packages that may need to be built differently for a RHEL-like
target as compared to a Fedora one. (For example, we may want to skip
regenerating documentation during package-build and instead use
pre-built docs from the tarball or SRPM.)
This includes:
* buildroot configuration, rpm macro and compile flags,
* comps files and the compose content,
* compose itself and the pipeline which builds it.
Under this umbrella we are going to have:
* RPM variables for conditionals to allow tweaking rpm spec files
* A new Koji tag which allows control of the buildroot,
* A fork of the pungi configuration which describes the compose configuration,
* A pipeline which builds a periodic compose based on that configuration,
* Storage for such composes and additional pipelines which will verify
the quality of the compose and test additional scenarios on top of it.
The RPM variables:
* `%{dist}` will return `.eln` (no numerical suffix)
* `%{fedora}` will return `.fcXX` (where XX is the Fedora version
represented by Rawhide).
* `%{rhel}` will be set and will return a number one higher than the
most recent major release of Red Hat Enterprise Linux (at present,
that will be `9`).
* `%{eln}` will be set and will expand to `%{rhel}`
The reasoning behind this approach is so that we break as little as
possible when we implement this new build and compose. Existing
packages that are using conditionals such as `if 0%{?rhel} > 7` will
transition over to building "like RHEL" automatically. Any packages
that do not have a shared Fedora/RHEL specfile will continue to build
as normal. Some unknown number of packages that rely on `if !
0%{?fedora}` will require manual intervention.
The `%{eln}` variable will be set primarily to allow for the
possibility of needing conditionals that apply to ELN only and should
not carry over to RHEL, but we expect its use to be exceptionally
rare.
== Benefit to Fedora ==
Who benefits from the implementation of this feature:
* Fedora Infrastructure
** As we are going to try and test new, more easily maintainable
infrastructure for composes.
* Fedora Minimization
** As we are going to modify the compose content according to
minimization goals and provide feedback to Fedora maintainers on the
results
* CentOS Stream, EPEL and RHEL
** We are going to build Fedora packages into a compose similar to the
multi-repo structure of CentOS and RHEL.
* Fedora Community
** The feedback pipelines built for the project will allow downstream
developers to open up their work and bring it closer to Fedora. In
particular, it will enable projects like OpenShift to do their work in
Fedora.
** Making Fedora friendlier to its downstream will justify bringing
more resources and more contributions to Fedora Rawhide. So that
downstream not only tries to catch up with Fedora going forward, but
actively participates in Fedora development and testing.
** The tooling developed for this project will allow further
development of changes in Fedora Infrastructure without blocking the
regular Fedora packaging and release process.
== Scope ==
* Proposal owners:
** Setup build environment for a new disttag (`eln`).
** Setup automation to trigger new ELN build every time there is a new
update submitted to Fedora Rawhide.
** Post build result to Fedora Messaging, so that it appears in Bodhi
and can be used as a
[https://docs.fedoraproject.org/en-US/rawhide-gating/ gating test].
** Setup automation to run periodic partial composes (via ODCS)
without installation media to generate repositories with these
packages.
** Update packaging documentation to mention new disttag and how it can be used.
* Other developers:
*: Anyone who wants to produce different content for the ELN compose
will need to implement the new macros in their specfile. The
overwhelming majority of packages will require no modification.
* Release engineering: [https://pagure.io/releng/issue/9154 #9154]
* Policies and guidelines:
[https://pagure.io/packaging-committee/issue/955 #955]
* Trademark approval: not needed. There is no new shippable artifact.
== Upgrade/compatibility impact ==
N/A
Though it is a System Wide change it doesn’t impact Fedora upgrades,
as it is a development environment tracking Fedora Rawhide.
== How To Test ==
There is going to be a development snapshot of the state of the ELN
repositories.
It is under discussion whether this snapshot will have its own
installation media. For now the preferred way to test ELN composes
would be to use standard Fedora Rawhide images and then include ELN as
an additional repository.
== User Experience ==
There is no user-facing part in this change. No ELN artifacts are
going to be shipped to the end-user.
== Dependencies ==
There is no dependency on other changes, though some of the
infrastructure services like ODCS composes and Fedora CI will be
involved.
== Contingency Plan ==
* Contingency mechanism: If this effort doesn’t land in Fedora 33 we
review it and decide whether it needs to be moved further to Fedora 34
or cancelled.
* Contingency deadline: N/A as it is a continuous process in Fedora
Rawhide and it is not pinned to a specific release.
* Blocks release? No
* Blocks product? No
Additional risk: Infrastructure resources taken by ELN builds can
create load on Fedora build system
Mitigation: In case of such load we cancel or reschedule ELN tasks
(package and compose builds and tests) on request from the Fedora
Infrastructure team. At least initially, we will also set ELN tasks to
low-priority, similar to how COPR does it.
== Documentation ==
https://fedoraproject.org/wiki/ELN
See also previous discussions:
* "Alternative buildroot as a development tool" @ devel
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
== Release Notes ==
N/A
Though it is a System-Wide Change it has no user-facing component. We
may announce it through other channels.
--
Aleksandra Fedorova
bookwar