I'm planning a soname bump from 11 to 12 in libavif for version 0.9.2.
The affected packages are:
I will rebuild them using my PP.
If anyone has a question regarding this, feel free to leave any input.
I had a hard time trying to describe what I'm talking about, perhaps
there's actually a term for it, but as I go through all the dependencies of
OpenEXR I wanted to know if this is a problem or not which I think is best
shown by example:
So part of the dependency chain for blender is:
So is it OK for OpenVDB to link against OpenEXR 2.x (openexr2) while
Blender links with OpenEXR 3.x? Or does the whole dependency stack need to
be upgraded at one time?
I use and like vim-syntastic, so I took it from the orphan list.
There is an open bug on it that led to its retirement, that the rnc
subpackage fails to install because rnv is no longer available.
It's straightforward enough to stop building the -rnc subpackage for
vim-syntastic, but do I also need to obsolete older versions of the
== Summary ==
Update mechanism for opting-in to "Third-Party Software Repositories"
so that the repositories are immediately enabled.
== Owner ==
* Name: [[User:otaylor| Owen Taylor]]
* Email: otaylor(a)redhat.com
== Detailed Description ==
''''''Note that this proposal is about a change to how third-party
repositories are enabled, not about including anything new in
Currently, when the user opts in to "Enable Third-Party Software
repositories", the` fedora-workstation-repositories` package is
installed, but with the repositories disabled.
With this change, `fedora-workstation-repositories` will be installed
by default (required by `fedora-release-workstation`), and opting in
to "Third-party Software Repositories" will actually enable the
Fedora Workstation Issue:
[https://pagure.io/fedora-workstation/issue/105 #105 Ship
fedora-workstation-repositories on install media]
== Conformance to Fedora policies ==
Third-Party Repository Policy]:
The third-party nature of the repository must be apparent to the user
when they enable it, as should the non-free status of its content, if
such. To ensure this, repository files must initially include the
enabled=0 (or equivalent) setting, and the user must explicitly enable
third-party repositories to install from them.
This proposals is a new implementation of "explictly enable
third-party repositories". There is no proposed change to which
third-party repostories are shipped - and in particular this change
does not include splitting fedora-workstation-repositories to conform
to the recommendation of the current guidelines.
== Technical implementation ==
* There is a <code>fedora-third-party</code> package with a
<code>fedora-third-party</code> script with
<code>enable/disable/refresh/query</code> subcommands. The status is
stored in <code>/etc/fedora-third-party.conf</code>
* Packages like <code>fedora-workstation-repositories</code> that
include third-party repositories will drop config files into
<code>/etc/fedora-third-party.d/*.conf</code>. There will be a
post-transaction file trigger to run <code>fedora-third-party
refresh</code>, which applies the users opt-in status to newly
installed repository files.
* We add a new page to GNOME Initial Setup that asks a single
question, *along the lines of*:<br>
'''Enable Third Party Software repositories?''' <br>
☑ Access additional software from selected third party sources. Some
of this software is proprietary and therefore has restrictions on use,
sharing, and access to source code. <br>
[Find out more...](https://fedoraproject.org/wiki/Workstation/Third_Party_Software_...
* If the user leaves the box checked, GNOME Initial setup runs
* For upgrades, GNOME Software shows an info-bar with the same
question if no status is stored in `/etc/fedora-thirdparty.conf`
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
== Benefit to Fedora ==
The main benefit of this proposal is the removal of the state where
the user has opted in to third party repositories but they are not
actually enabled. PackageKit supports the
<code>enabled_metadata=1</code> key in a repository file, which allows
applications to be searched in this state, but this is not supported
The new method is also easily extensible to Flatpaks, where there also
no equivalent to <code>enabled_metadata=1</code>, even in GNOME
== Scope ==
* Proposal owners: Create and test proposed
<code>fedora-third-party</code> package. Implement the graphical
controls for this in GNOME Software and gnome-initial-setup.
* Release engineering: [https://pagure.io/releng/issue/10186 #10186]
No changes are required.
* Policies and guidelines: Third-party Software guidelines will need
minor changes to remove references to `enabled_metadata=1`. Pending
finalization of technical implementation.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No real alignment
== Upgrade/compatibility impact ==
Because the "opt-in" status to 3rd party software is currently
represented by whether fedora-workstation-repositories is installed,
and because fedora-workstation-repositories will become an
installed-by-default package, users will need to opt-in again.
They can do this either by responding in the infobar that will be
displayed in GNOME Software, or by running <code>fedora-third-party
enable</code> on the command line.
== How To Test ==
* A fresh install of Fedora Workstation where the user ''does not''
opt-in should have all repositories disabled.
* A fresh install of Fedora Workstation where the user ''does'' opt-in
should have all 3rd-party repositories enabled.
* On an upgrade from F34, if the user opts-out, the enablement status
of third-party repositories should be ''unchanged'' (try enabling one
before the upgrade)
* On an upgrade from F35, if the user opts-in, all 3rd party
repositories should be enabled.
== User Experience ==
The user will get less confusing behavior around third-party
repositories - enabled will mean enabled and will take affect no
matter how they are installing packages.
See https://hackmd.io/@owtaylor/fedora-third-party-repos for a
detailed description of the *current* experience along with some notes
about the desired behavior.
== Dependencies ==
The changes are limited to the following packages:
* The new `fedora-third-party` package
* `fedora-release-workstation` and other release packages that will
now require fedora-workstation-repositories.
This change proposal is a prerequisite for a separate change proposal
to add a filtered view of Flathub to the set of third-party
== Contingency Plan ==
* Contingency mechanism: revert all changes back to the F34 state.
(This will also require reverting the filtered-view-of-Flathub
* Contingency deadline: beta freeze
* Blocks release? Yes - this needs to be finished or reverted
== Documentation ==
'''This should be a link to a man page for the `fedora-third-party` tool'''
== Release Notes ==
Fedora optionally provides repository definitions allowing users to
install certain third-party software. This used to be done as a
two-step process where when the user asked to enable third-party
repositories, the repository definitions were installed but not
actually enabled, and they had to be separately enabled. With Fedora
35, this is simplified so that the repository definitions are
installed by default, but only enabled if the user opts in.
If you are upgrading from an older version of Fedora, you'll need to
opt-in again - this can be done by running GNOME Software and
accepting the prompt that is shown on the initial page. Alternatively,
you can run <code>fedora-third-party enable</code> from the command
line. If you do not wish to enable third-party repositories, no action
He / Him / His
Fedora Program Manager
NOTE: This is part of the ongoing saga that is the OpenEXR project. As of
2.5.5 IlmBase was absorbed into the main OpenEXR library, and then with 3.x
imath was split out as a standalone library.
I've built openexr2 since many packages don't support openexr 3.x. I also
set openexr2-devel to conflict with openexr-devel since they should not be
installed at the same time. The project either supports OpenEXR 3 or it
The question is I'm currently renaming the pkgconfig and cmake modules to
have a "2" at the end. This makes specifying which one in a spec file easy,
but this could mean having to patch the build systems of the projects that
Does it work, and/or is it acceptable to put a less than version
BuildRequires: pkgconfig(IlmBase) < 3
In the spec file instead? This would be much easier.