Hi,
Seems my effort to deduplicate @gnome-desktop and @fedora-workstation got reverted again, because it breaks upgrades from F23 -> F24 via dnf when @gnome-desktop is not installed, which is the expected and default case. dnf wants to remove all of GNOME because it's no longer present in @fedora-workstation, and @gnome-desktop is not already installed.
I don't think we want to continue to maintain these groups separately, it leads to many "bugs" (unexpected differences) between the two groups, with developers accidentally editing one but not the other. So: does anyone have any suggestions to avoid this problem?
The best solution I could come up with is to simply tell users to 'sudo dnf install @gnome-desktop' before upgrading with dnf, and list this on the known problems wiki page. Since gnome-software is now our default and expected method for upgrading Fedora Workstation, I think it's OK for there to be some hiccups when upgrading with dnf, but it would still be really nice to have some way to handle this automatically... could we somehow make the one group depend on the other, for instance?
How does gnome-software handle this issue?
Michael
On 26 February 2016 at 20:53, Michael Catanzaro mcatanzaro@gnome.org wrote:
How does gnome-software handle this issue?
The same way as dnf, i.e. with package deps. :(
Richard.
I'm not 100% up to speed on the intrinsics of dependency resolution, so there could be a million different ways that this could break that I don't realize BUT... What happens if we push an update to @gnome-desktop that has @fedora-workstation as a dependency? Then do a second update that has @fedora-workstation obsoleting @gnome-desktop? On Feb 26, 2016 15:55, "Richard Hughes" hughsient@gmail.com wrote:
On 26 February 2016 at 20:53, Michael Catanzaro mcatanzaro@gnome.org wrote:
How does gnome-software handle this issue?
The same way as dnf, i.e. with package deps. :(
Richard.
desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Fri, 2016-02-26 at 16:09 -0500, Eric Griffith wrote:
I'm not 100% up to speed on the intrinsics of dependency resolution, so there could be a million different ways that this could break that I don't realize BUT... What happens if we push an update to @gnome-desktop that has @fedora-workstation as a dependency? Then do a second update that has @fedora-workstation obsoleting @gnome-desktop?
I am not sure you can make a group depend on another group. This is what environment groups are for. The workstation-product-environment group already depends on both @gnome-desktop (the new dep in F24) and @workstation-product, and dnf shows this if you run 'dnf group info workstation-product-environment'.
On 02/26/2016 09:53 PM, Michael Catanzaro wrote:
Hi,
Seems my effort to deduplicate @gnome-desktop and @fedora-workstation got reverted again, because it breaks upgrades from F23 -> F24 via dnf when @gnome-desktop is not installed, which is the expected and default case. dnf wants to remove all of GNOME because it's no longer present in @fedora-workstation, and @gnome-desktop is not already installed.
I don't think we want to continue to maintain these groups separately, it leads to many "bugs" (unexpected differences) between the two groups, with developers accidentally editing one but not the other. So: does anyone have any suggestions to avoid this problem?
Maybe just remove @gnome-desktop ? We don't really have a gnome desktop spin any more, so it doesn't make that much sense to keep it around.
I think this was the plan all along, it was just that the workstation groups landed late in the F21 cycle and it was too late to remove @gnome-desktop at that point without potentially breaking other spins that were using it.
The best solution I could come up with is to simply tell users to 'sudo dnf install @gnome-desktop' before upgrading with dnf, and list this on the known problems wiki page. Since gnome-software is now our default and expected method for upgrading Fedora Workstation, I think it's OK for there to be some hiccups when upgrading with dnf, but it would still be really nice to have some way to handle this automatically... could we somehow make the one group depend on the other, for instance?
I don't think that having users install a group manually to unbreak upgrades is the way to go here. It feels like we're asking users to work around things that should just work out of the box.
If it means that we need to keep @gnome-desktop around for a few more releases, so be it. The tradeoff in this case, where in one case we'd have to keep an obsolete group around vs the alternative of requiring users to manually install a group seems like it has a clear winner, at least in my mind.
Also,
How does gnome-software handle this issue?
I don't think it has any comps handling at all. It just operates on packages.
On Sat, 2016-02-27 at 11:30 +0100, Kalev Lember wrote:
Maybe just remove @gnome-desktop ? We don't really have a gnome desktop spin any more, so it doesn't make that much sense to keep it around.
I think this was the plan all along, it was just that the workstation groups landed late in the F21 cycle and it was too late to remove @gnome-desktop at that point without potentially breaking other spins that were using it.
But then doesn't that just pass the problem off to the spins still using @gnome-desktop, and users that installed prior to F21? I guess that is a much smaller subset of users that will face the upgrade problem, though, so you're right, this is probably a better approach.
(It's also kind of nice to have a separation between the GNOME packages, and "extra" packages, but I can live without that....)
I don't think that having users install a group manually to unbreak upgrades is the way to go here. It feels like we're asking users to work around things that should just work out of the box.
If it means that we need to keep @gnome-desktop around for a few more releases, so be it. The tradeoff in this case, where in one case we'd have to keep an obsolete group around vs the alternative of requiring users to manually install a group seems like it has a clear winner, at least in my mind.
Well I agree it's not great, but if we have graphical upgrade tool that does work properly, I think we can reasonably expect users to use that, and anyone who tries the command line instead to apply a simple one- time workaround.
Though, I wonder if this would break 'dnf autoremove' as well... and that is not a one-time issue, but a permanent problem....
Michael
On Sat, Feb 27, 2016 at 08:26:40AM -0600, Michael Catanzaro wrote:
I think this was the plan all along, it was just that the workstation groups landed late in the F21 cycle and it was too late to remove @gnome-desktop at that point without potentially breaking other spins that were using it.
But then doesn't that just pass the problem off to the spins still using @gnome-desktop, and users that installed prior to F21? I guess that is a much smaller subset of users that will face the upgrade problem, though, so you're right, this is probably a better approach. (It's also kind of nice to have a separation between the GNOME packages, and "extra" packages, but I can live without that....)
From a high-level conceptual standpoint, I like the idea of @fedora-workstation including (e.g. being built on) @gnome-desktop, but being separate and additive. That reinforces the idea that the editions aren't merely upstream tech showcases which we are arbitrarily elevating over other possiblities. They're meant to be Fedora-focused marketing tools, in the complete sense of marketing — not just the part about ad copy and swag, but a whole deal where we look at market opportunities and try to build something that will fill them.
But, that shouldn't get in the way doing what works best pragmatically at this level. :)
On 02/27/2016 10:06 AM, Matthew Miller wrote:
On Sat, Feb 27, 2016 at 08:26:40AM -0600, Michael Catanzaro wrote:
I think this was the plan all along, it was just that the workstation groups landed late in the F21 cycle and it was too late to remove @gnome-desktop at that point without potentially breaking other spins that were using it.
But then doesn't that just pass the problem off to the spins still using @gnome-desktop, and users that installed prior to F21? I guess that is a much smaller subset of users that will face the upgrade problem, though, so you're right, this is probably a better approach. (It's also kind of nice to have a separation between the GNOME packages, and "extra" packages, but I can live without that....)
From a high-level conceptual standpoint, I like the idea of @fedora-workstation including (e.g. being built on) @gnome-desktop, but being separate and additive. That reinforces the idea that the editions aren't merely upstream tech showcases which we are arbitrarily elevating over other possiblities. They're meant to be Fedora-focused marketing tools, in the complete sense of marketing — not just the part about ad copy and swag, but a whole deal where we look at market opportunities and try to build something that will fill them.
But, that shouldn't get in the way doing what works best pragmatically at this level. :)
This isn't the problem. We have the Fedora Workstation environment group for that purpose. Environment groups contain package groups. Both @fedora-workstation and @gnome-desktop are package groups.
So there's an argument to be made that perhaps @fedora-workstation should go away and be replaced by @^workstation-product-environment entirely.
On Mon, 2016-02-29 at 10:24 -0500, Stephen Gallagher wrote:
This isn't the problem. We have the Fedora Workstation environment group for that purpose. Environment groups contain package groups. Both @fedora-workstation and @gnome-desktop are package groups.
So there's an argument to be made that perhaps @fedora-workstation should go away and be replaced by @^workstation-product-environment entirely.
I'm a bit late to this thread, but to me the duplication of @fedora- workstation and @gnome-desktop is dumb and needs to go away. @^workstat ion-product-environment (the env group) should use one package group as 'all the main GNOME desktop packages' and anything Workstation-y should include the the env group, anything just GNOME-y can include the package group.
I think we went over this on IRC, but I am rather suspicious of the original "bug". If the system has the workstation-product-environment env group installed, so long as the real package group is part of that env, stuff shouldn't get removed on a dnf upgrade. If it does, that's a clear bug in dnf, but I don't think it actually does. The "bug" in question does not actually appear to have been reported anywhere we could find. -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net
On Tue, 2016-03-08 at 10:42 -0800, Adam Williamson wrote:
I'm a bit late to this thread, but to me the duplication of @fedora- workstation and @gnome-desktop is dumb and needs to go away. @^workstat ion-product-environment (the env group) should use one package group as 'all the main GNOME desktop packages' and anything Workstation-y should include the the env group, anything just GNOME-y can include the package group.
I think we went over this on IRC, but I am rather suspicious of the original "bug". If the system has the workstation-product-environment env group installed, so long as the real package group is part of that env, stuff shouldn't get removed on a dnf upgrade. If it does, that's a clear bug in dnf, but I don't think it actually does. The "bug" in question does not actually appear to have been reported anywhere we could find.
Pete, do you have any comment on this? Otherwise I'm planning to roll this change back in later this week.
Michael
On Tue, 2016-03-08 at 17:47 -0600, Michael Catanzaro wrote:
Pete, do you have any comment on this? Otherwise I'm planning to roll this change back in later this week.
I'm going to do this now.
Kalev or Adam or someone with spins-kickstart access, I need you to revert this commit to bring the GNOME packages back on the live CDs:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=a08e27 a87d45ec7b5428d0c172b5d1bb3c505366
Thanks,
Michael
On Sat, 2016-03-12 at 10:13 -0600, Michael Catanzaro wrote:
On Tue, 2016-03-08 at 17:47 -0600, Michael Catanzaro wrote:
Pete, do you have any comment on this? Otherwise I'm planning to roll this change back in later this week.
I'm going to do this now.
Kalev or Adam or someone with spins-kickstart access, I need you to revert this commit to bring the GNOME packages back on the live CDs:
https://git.fedorahosted.org/cgit/spin-kickstarts.git/commit/?id=a08e27 a87d45ec7b5428d0c172b5d1bb3c505366
Done. -- Adam WilliamsonFedora QA Community MonkeyIRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . nethttp://www.happyassassin.net
desktop@lists.fedoraproject.org
-
Adam Williamson -
Eric Griffith -
Kalev Lember -
Matthew Miller -
Michael Catanzaro -
Richard Hughes -
Stephen Gallagher