Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1435423 - Need to fix wallpaper / background packaging situation
Summary: Need to fix wallpaper / background packaging situation
Alias: None
Product: Fedora
Classification: Fedora
Component: desktop-backgrounds
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Martin Sourada
QA Contact: Fedora Extras Quality Assurance
: 1319865 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2017-03-23 18:26 UTC by Máirín Duffy
Modified: 2021-04-06 02:12 UTC (History)
18 users (show)

Fixed In Version: desktop-backgrounds-34.0.0-2.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-04-05 00:17:29 UTC
Type: Bug

Attachments (Terms of Use)

Description Máirín Duffy 2017-03-23 18:26:23 UTC
Description of problem:

The packaging bits for providing the default desktop background are overcomplicated and cause issues every release. On top of that, there is a new source package every release, so every release we need to do a new package review. Once the new package is in, we have to adjust stuff in comps/spin-kickstarts. 

Just using one package with subpackages could save a lot of pain. There is legitimate complexity here, but someone should sit down and think about how this works and come up with a better approach - it should be possible but it's never on anybody's priority list until we get into another situation with wallpapers blocking the release. 

Going to no alphas in favor of rawhide serving as alpha, we need to change how it works anyway.

Roshi offered to write a script to autogenerate a placeholder wallpaper that could be used until draft artwork was ready.

Idea from today's F26 alpha go/no-go meeting:

1) After branch you make that have the current release stuff and move the previous one to desktop-backgrounds-f25 subpackage
2) maybe just one source package is OK, it'd have a lot of subpackages but you could just keep them around for as long as you want and the subpackages should have virtual provides
3) when we get to final, we push it to N+1 and at that point it never is an issue again

Another idea:

1) the real problem we have here is a) there's far too much unnecessary work to do each cycle to actually meet the requirements and b) no-one seems to have taken responsibility for making sure all that work gets done every cycle, even though it's completely predictable and plannable-for
and it should be someone's job as soon as possible after branching to put in the 'real' wallpaper for the release
2) the placeholder wallpaper should just always be in rawhide
3) when we branch the package is updated to the new one
4) the neat thing about doing it that way is that as long as the real wallpaper gets in *some time* before release, we're good, because then all pre-release builds would kinda 'automatically' have different wallpaper from all final releases
5) the placeholder wallpaper can always stay the same or just be changed when someone gets bored of it. it doesn't really matter so long as it's never the same as any final release wallpaper

Nirik has volunteered to look into this. CCing adamw, sgallagh, and nb based on their participation / interest.

Comment 1 Luya Tshimbalanga 2017-03-23 18:31:22 UTC
Here is the initial concept on

Comment 2 Adam Williamson 2017-03-23 19:50:05 UTC
So to combine and summarize my ideas:

* There should be just one, unversioned, source package for the actual images (what goes in the versioned source packages currently). Let's call it, for argument's sake, 'fedora-backgrounds'.

* There is a single subpackage of that source package which contains the artwork that is *always* used for Rawhide. This artwork should *never* be the same as the artwork for any stable release, and it should clearly indicate that you're running something unstable (a jokey image, like something with Beefy, would be a good idea). Let's call it 'fedora-backgrounds-rawhide'.

* For each new release, soon after branching, we add a new subpackage to the source package containing the artwork for that release. Let's call these 'fedora-26-backgrounds', 'fedora-27-backgrounds', etc. (To be clear, I'm not stuck on these names, they're just ones I'm using for the purpose of this proposal). We also change the 'desktop-backgrounds' package on the branch to require the new release versioned 'fedora-backgrounds' subpackages. The Rawhide 'desktop-backgrounds' package should always require 'fedora-backgrounds-rawhide', and at branch point it should be rebuilt so it is higher versioned than the version on the branch. Any necessary changes to kickstarts and comps should also be made at this time. Ideally we should go through how all the desktops implement their backgrounds and try to harmonize them as much as possible, to reduce the amount of stuff that needs to be done.

* There should be an SOP documenting all these actions, and it should be a specific team's responsibility to do it by a certain point for every release, and the FPM's responsibility to check and make sure it gets done by that point.

That's basically my proposal. If anyone can think of a better way to finesse the packaging bits so less work is required at each branch point, please do suggest it, that's the best I could do. Also yell if you can think of a part of the process I didn't consider.

Comment 3 Kevin Fenzi 2017-03-23 20:02:03 UTC
Swapping emails to the one I use for bugzilla. :) 

My idea is basically a single source package, 'desktop-backgrounds' that replaces making a new fN one each cycle. Then, at branching, we rebuild the rawhide one (to keep upgrade path) and the branched one (to move the 'current' backgrounds to a new fN subpackage and point the current ones at the same 'placeholder' ones as rawhide. Then when artwork is ready, branched is just updated to point the current subpackages at the new artwork and we are done. 

So basically similar to what adam suggests with less detail. ;) 

We could either just keep around the old subpackages (in case someone wants to install / use them) or just drop them at branch time too if we don't want them packaged anymore. 

I'll try and dig into this at some point, but not sure when...

Oh, Nice to haves: 

* Can we make it so there's no changes to comps/spin-kickstarts needed?

* Can we make it so no other packages need to change? wasn't there a kde package that needs to have the number hard coded or something?

* If we are doing a bunch of things at branching, perhaps we could get releng to do these things when they update fedora-release and fedora-repos?

Comment 4 Adam Williamson 2017-03-23 21:00:56 UTC
"Can we make it so there's no changes to comps/spin-kickstarts needed?"

IIRC (I'll have to refresh my memory on this), this is basically what the current desktop-backgrounds package is intended for: the idea is that comps groups and kickstart files should include desktop-backgrounds subpackages, and the desktop-backgrounds subpackages should require the appropriate fXX-backgrounds package. The problem is, again IIRC, that some desktops don't actually bother using this system, and just list fXX-backgrounds directly in comps/kickstarts.

Comment 5 Adam Williamson 2017-03-28 06:27:05 UTC
So today I got to figure out the KDE wrinkles :/

For F26, KDE didn't get the correct appearance even after:

1) f26-backgrounds is created
2) desktop-backgrounds is bumped
3) comps and kickstarts are updated

It seems two changes are needed to the kde-settings package. Firstly, the kde-settings-plasma subpackage has a direct dependency on fXX-backgrounds that has to be incremented (from f25-backgrounds to f26-backgrounds, in the F26 case). Secondly, there's a file in the package *source* that has to be changed: usr/share/kde-settings/kde-profile/default/xdg/plasmarc . It specifies the name of the default Plasma theme (I think), and that name is versioned - so for the F26 case, I had to bump it from 'F25' to 'F26'.

So obviously if we want to make this not suck, we need to rejig the KDE/Plasma bits so no-one has to change this stuff in kde-settings every cycle.

Comment 6 Rex Dieter 2017-03-28 11:37:48 UTC
If I recall, during f25 development, I made efforts to make the wallpaper setup for kde spin much simpler.

One last snag I ran into Adam highlighted in comment #5... I would've liked to make the Plasma theme unversioned, but that would also mean the background name, files, and/or themename it provides needs to be unversioned or static too (ie, it likely requires changes on both sides).

Comment 7 Rex Dieter 2017-03-30 12:46:33 UTC
So, no response to my comment #6 yet, so I'll be more specific to address item 2 "nice to have" from comment #3:

If there is a desire to make new wallpaper/backgrounds 'just work' in kde spin without making further changes, then the default wallpaper theme name needs to be the same between fedora releases too.

for example, there's this,
(provided by desktop-backgrounds-compat)

which is used already in several places.  A downside to this is that it's a single image (and doesn't support varying resolutions/form-factors).

What I'd like, is there to be something like:
whatever (I don't care what it's called, can bikeshed that later), and matching plasma-styled items under /usr/share/wallpapers, which always points to whatever is the default wallpaper for any particular fedora release.

Implementing this introduces one extra complication to new fedora releases: When and how to flip whatever provides this new static wallpaper (ie, only one package can and should provide it at any given time).  For example, when f26-backgrounds is introduced, then f25-backgrounds will need to be modified to drop providing the default one.

Comment 8 Jan Kurik 2017-08-15 08:05:36 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 9 Ben Cotton 2018-11-27 17:14:44 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 10 Adam Williamson 2018-11-27 19:53:39 UTC
*** Bug 1319865 has been marked as a duplicate of this bug. ***

Comment 11 Fedora Update System 2021-04-01 06:24:08 UTC
FEDORA-2021-efd2ac9517 has been submitted as an update to Fedora 34.

Comment 12 Fedora Update System 2021-04-02 01:34:46 UTC
FEDORA-2021-efd2ac9517 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-efd2ac9517`
You can provide feedback for this update here:

See also for more information on how to test updates.

Comment 13 Fedora Update System 2021-04-05 00:17:29 UTC
FEDORA-2021-efd2ac9517 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 14 Luya Tshimbalanga 2021-04-06 02:12:33 UTC

Note You need to log in before you can comment on or make changes to this bug.