On Fri, Jan 21, 2011 at 11:03:02 -0500, "Clyde E. Kunkel" clydekunkel7734@cox.net wrote:
Should they be visible?
I am not sure, but on a possibly related note, neither metacity nor gnome-panel end up running and I have to manually start them to get a usable desktop. I am not sure if they don't get started or crash. I filed bugs for both of these.
2011/1/21 Bruno Wolff III bruno@wolff.to
On Fri, Jan 21, 2011 at 11:03:02 -0500, "Clyde E. Kunkel" clydekunkel7734@cox.net wrote:
Should they be visible?
I am not sure, but on a possibly related note, neither metacity nor gnome-panel end up running and I have to manually start them to get a usable desktop. I am not sure if they don't get started or crash. I filed bugs for both of these.
it may be related to a message about rt-kit being unable to become
<something i don't remember>.
anyway, gnome + openbox works, somehow.
On 01/21/2011 12:36 PM, Andre Robatino wrote:
Wow, this bug is four months old and no indication what is actually wrong except maybe something to do with nautilus. The workarounds in the bz don't work for me. Do we ping Tomáš Bžatek? Maybe he has more information. I'll include him on this reply.
Regards, OldFart
2011/1/22 Matthias Clasen mclasen@redhat.com
On Fri, 2011-01-21 at 11:03 -0500, Clyde E. Kunkel wrote:
Should they be visible?
GNOME 3 will not start nautilus by default. Sorry, I should have probably announced this change hitting rawhide.
oh, but should it start panels? or at least the gnomeshell?
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
There perhaps needs to be a check that gnome-shell is installed as well. As I don't seem to have it installed and I don't get gnome-panel+metacity started.
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
That is a good point. We should perhaps add a gnome-session -> gnome-shell dependency.
On Sat, Jan 22, 2011 at 7:05 PM, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
That is a good point. We should perhaps add a gnome-session -> gnome-shell dependency.
Please don't. There's a lot of devices that can't run gnome-shell but can run the gnome 2 configuration perfectly. With dependencies like that on devices with small amounts of space you end up with a lot of extra stuff you don't want or need. There must some other way to achieve it for those that want it without forcing those that can't have or don't want it to have unnecessary isssues and deps.
Given that "yum upgrade" isn't a fully supported method for upgrade I don't see any issue with documenting that they then need to do a "yum groupinstall gnome3" as the documented ways of doing yum upgrade have always suggested to do similar to get new apps that weren't previously installed.
Peter
On Sat, Jan 22, 2011 at 19:16:59 +0000, Peter Robinson pbrobinson@gmail.com wrote:
Please don't. There's a lot of devices that can't run gnome-shell but can run the gnome 2 configuration perfectly. With dependencies like that on devices with small amounts of space you end up with a lot of extra stuff you don't want or need. There must some other way to achieve it for those that want it without forcing those that can't have or don't want it to have unnecessary isssues and deps.
Ideally, I'd think you'd want to have it pulled in by default when going from F13 or F14 to F15 (and probably F16) and then be able to removed it manually. I don't know if there is some trickery with obsoletes that might get this to work.
Given that "yum upgrade" isn't a fully supported method for upgrade I don't see any issue with documenting that they then need to do a "yum groupinstall gnome3" as the documented ways of doing yum upgrade have always suggested to do similar to get new apps that weren't previously installed.
Preupgrades are officially supported. Do preupgrades have a way of specifying that certain packages should be included without creating a hard dependency?
Also it seems that right now gnome-shell is a hard dependency for gnome as metacity (at least, I don't know about compiz) doesn't get started by default when gnome-shell is missing. I think that's probably just an oversight, but they may be something more complex going on.
On Sat, Jan 22, 2011 at 7:31 PM, Bruno Wolff III bruno@wolff.to wrote:
On Sat, Jan 22, 2011 at 19:16:59 +0000, Peter Robinson pbrobinson@gmail.com wrote:
Please don't. There's a lot of devices that can't run gnome-shell but can run the gnome 2 configuration perfectly. With dependencies like that on devices with small amounts of space you end up with a lot of extra stuff you don't want or need. There must some other way to achieve it for those that want it without forcing those that can't have or don't want it to have unnecessary isssues and deps.
Ideally, I'd think you'd want to have it pulled in by default when going from F13 or F14 to F15 (and probably F16) and then be able to removed it manually. I don't know if there is some trickery with obsoletes that might get this to work.
Well you'd want to be able to exclude it as well and adding it as an artificial dep to something like gnome-session won't allow it to be removed.
Given that "yum upgrade" isn't a fully supported method for upgrade I don't see any issue with documenting that they then need to do a "yum groupinstall gnome3" as the documented ways of doing yum upgrade have always suggested to do similar to get new apps that weren't previously installed.
Preupgrades are officially supported. Do preupgrades have a way of specifying that certain packages should be included without creating a hard dependency?
Also it seems that right now gnome-shell is a hard dependency for gnome as metacity (at least, I don't know about compiz) doesn't get started by default when gnome-shell is missing. I think that's probably just an oversight, but they may be something more complex going on.
Metacity works fine for me in rawhide
Peter
On Sat, Jan 22, 2011 at 14:32, Peter Robinson pbrobinson@gmail.com wrote:
Well you'd want to be able to exclude it as well and adding it as an artificial dep to something like gnome-session won't allow it to be removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell from the gnome-session from GNOME 3 is not artificial but rather a requirement. The fallback mode is intended as a fallback for driver and VM problems, not as first-class desktop environment. You will be allowed to force it to use the fallback mode should the detection fail to understand your hardware but that's not quite there yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and explaining why) from a user perspective than, "If you drivers don't work do this magic with the package manager." The former is helpful; the later is pain.
On Sat, Jan 22, 2011 at 8:56 PM, Jason D. Clinton me@jasonclinton.com wrote:
On Sat, Jan 22, 2011 at 14:32, Peter Robinson pbrobinson@gmail.com wrote:
Well you'd want to be able to exclude it as well and adding it as an artificial dep to something like gnome-session won't allow it to be removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell from the gnome-session from GNOME 3 is not artificial but rather a requirement. The fallback mode is intended as a fallback for driver and VM problems, not as first-class desktop environment. You will be allowed to force it to use the fallback mode should the detection fail to understand your hardware but that's not quite there yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and explaining why) from a user perspective than, "If you drivers don't work do this magic with the package manager." The former is helpful; the later is pain.
what about users choice? Isn't that what free software is about?
Peter
On Sat, Jan 22, 2011 at 11:22 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Jan 22, 2011 at 8:56 PM, Jason D. Clinton me@jasonclinton.com wrote:
On Sat, Jan 22, 2011 at 14:32, Peter Robinson pbrobinson@gmail.com wrote:
Well you'd want to be able to exclude it as well and adding it as an artificial dep to something like gnome-session won't allow it to be removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell from the gnome-session from GNOME 3 is not artificial but rather a requirement. The fallback mode is intended as a fallback for driver and VM problems, not as first-class desktop environment. You will be allowed to force it to use the fallback mode should the detection fail to understand your hardware but that's not quite there yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and explaining why) from a user perspective than, "If you drivers don't work do this magic with the package manager." The former is helpful; the later is pain.
what about users choice? Isn't that what free software is about?
https://www.redhat.com/archives/fedora-devel-list/2008-January/msg00861.html
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies you want to. You don't have the freedom to insist that packagers support that use case.
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies you want to. You don't have the freedom to insist that packagers support that use case.
So what are all the people that don't have video cards suppose to do that don't support 3D. Use KDE? I thought gnome was continuing to support that use case?
Peter
On Sun, Jan 23, 2011 at 12:05 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies you want to. You don't have the freedom to insist that packagers support that use case.
So what are all the people that don't have video cards suppose to do that don't support 3D. Use KDE? I thought gnome was continuing to support that use case?
And it still does ... in that case it will start metacity and gnome-panel even without user interaction. (which has nothing to do with package dependencies other than a few megabytes of disk space that aren't worth worrying about imo).
Am Sonntag, den 23.01.2011, 00:07 +0100 schrieb drago01:
On Sun, Jan 23, 2011 at 12:05 AM, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies you want to. You don't have the freedom to insist that packagers support that use case.
So what are all the people that don't have video cards suppose to do that don't support 3D. Use KDE? I thought gnome was continuing to support that use case?
And it still does ... in that case it will start metacity and gnome-panel even without user interaction. (which has nothing to do with package dependencies other than a few megabytes of disk space that aren't worth worrying about imo).
It's not (only) about a few megabytes on installed system but about space on the install media and especially on the spins. With this change, we would get gnome-shell on almost any spin and they all would be larger than CD size then.
Regards, Christoph
On 1/22/2011 6:05 PM, Peter Robinson wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies you want to. You don't have the freedom to insist that packagers support that use case.
So what are all the people that don't have video cards suppose to do that don't support 3D. Use KDE? I thought gnome was continuing to support that use case?
IMO.
t is the users of KDE that are entwined with K<some_name> applications. :-)
That is not the case with Gnome users. When Fedora 'broke'? the Gnome Desktop in Fedora 15/Rawhide I switched to XFCE. I still use the same major applications. The same Fedora GUI configuration applications. The only 'new things' <gasp> that I had to get used to was a slightly different looking terminal window, a slightly different looking file manger, and a slightly different looking desktop. That took about 10 minutes.
On Sat, 2011-01-22 at 23:05 +0000, Peter Robinson wrote:
On Sat, Jan 22, 2011 at 10:57 PM, Matthew Garrett mjg59@srcf.ucam.org wrote:
On Sat, Jan 22, 2011 at 10:22:28PM +0000, Peter Robinson wrote:
what about users choice? Isn't that what free software is about?
You have the freedom to modify the packages to remove any dependencies you want to. You don't have the freedom to insist that packagers support that use case.
So what are all the people that don't have video cards suppose to do that don't support 3D. Use KDE? I thought gnome was continuing to support that use case?
Yes, thats the much-talked about fallback. Supporting that does not mean that we have to support only installing the half of the desktop you want.
So what are all the people that don't have video cards suppose to do that don't support 3D. Use KDE? I thought gnome was continuing to support that use case?
Yes, thats the much-talked about fallback. Supporting that does not mean that we have to support only installing the half of the desktop you want.
maybe the problem is somewhere else: why gnome does not switch to plan b if gnome-shell is not installed?
Am Samstag, den 22.01.2011, 14:56 -0600 schrieb Jason D. Clinton:
On Sat, Jan 22, 2011 at 14:32, Peter Robinson pbrobinson@gmail.com wrote: Well you'd want to be able to exclude it as well and adding it as an artificial dep to something like gnome-session won't allow it to be removed.
GNOME Shell is the shell of GNOME 3 and thus depending on the GNOME Shell from the gnome-session from GNOME 3 is not artificial but rather a requirement.
There is not technical reason why gnome-session needs to depend on gnome-shell, this the dependency is artificial.
If the only purpose is is to pull something in during an update there are smarter ways, e.g. let a virtual package that depends on gnome-shell provide/obsolete something that was installed before.
The fallback mode is intended as a fallback for driver and VM problems, not as first-class desktop environment.
But that doesn't mean that the default always needs to be installed, does it?
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks). There are other use cases as well, say computers with limited hardware.
I really hope GNOME has learned a lesson from the KDE4 transition and will work on providing a sane fallback, otherwise they will loose many users just as KDE did.
You will be allowed to force it to use the fallback mode should the detection fail to understand your hardware but that's not quite there yet. See here:
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00008.html
http://mail.gnome.org/archives/desktop-devel-list/2011-January/msg00138.html
So, doing what you describe from the UI makes a lot more sense (and explaining why) from a user perspective than, "If you drivers don't work do this magic with the package manager." The former is helpful; the later is pain.
It's not "If you drivers don't work do this magic with the package manager." but more "Our fallback doesn't work properly and we use the package manager to fix it."
Regards, Christoph
On Sun, Jan 23, 2011 at 17:28:03 +0100, Christoph Wickert christoph.wickert@googlemail.com wrote:
If the only purpose is is to pull something in during an update there are smarter ways, e.g. let a virtual package that depends on gnome-shell provide/obsolete something that was installed before.
I was wondering if there would be a tricky way to do this kind of thing. Is there a more detailed write up of this procedure on the wiki somewhere? It seems like it would be good to capture this knowledge and try to put it somewhere where packages can find it.
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME 3. Moblin upstream seems only interested in being a complete OS and haven't cooperated well with other projects which want to include Moblin as a alternative UI in their distributions. Conman, trademark shenanigans etc. I understand the point you are trying to make but Moblin is really a poor example to pick.
Rahul
On Sun, Jan 23, 2011 at 5:12 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME 3. Moblin upstream seems only interested in being a complete OS and haven't cooperated well with other projects which want to include Moblin as a alternative UI in their distributions. Conman, trademark shenanigans etc. I understand the point you are trying to make but Moblin is really a poor example to pick.
Moblin is dead. MeeGo is somewhere between both arguments and there's network-manager-netbook replacement for connman, and the trademark issues are well and being dealt with and should be a non issue in time for F-15. Its also based on mutter, so its not that different from gnome-shell (hopefully even the fork might soon be resolved).
Peter
On 01/23/2011 10:58 PM, Peter Robinson wrote
Moblin is dead. MeeGo is somewhere between both arguments and there's network-manager-netbook replacement for connman, and the trademark issues are well and being dealt with and should be a non issue in time for F-15. Its also based on mutter, so its not that different from gnome-shell (hopefully even the fork might soon be resolved)
Good to know but so far I have been disappointed with them. Did the problem of srpm's having newer versions than what was available in their git branches get resolved as well?
Rahul
Am Sonntag, den 23.01.2011, 22:42 +0530 schrieb Rahul Sundaram:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME 3. Moblin upstream seems only interested in being a complete OS and haven't cooperated well with other projects which want to include Moblin as a alternative UI in their distributions. Conman, trademark shenanigans etc. I understand the point you are trying to make but Moblin is really a poor example to pick.
I agree it's a poor example and Ubuntu's Unity is yet another one because they don't cooperate well ether. Nevertheless all these are user interfaces based on GNOME technology. They are not default and seriously shouldn't be but it is a fact that there is more than just one desktop, more than just gnome-shell. Thus we should not force our users to install things they cannot use or don't want to.
Regards, Christoph
On Sun, Jan 23, 2011 at 7:19 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
Am Sonntag, den 23.01.2011, 22:42 +0530 schrieb Rahul Sundaram:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME 3. Moblin upstream seems only interested in being a complete OS and haven't cooperated well with other projects which want to include Moblin as a alternative UI in their distributions. Conman, trademark shenanigans etc. I understand the point you are trying to make but Moblin is really a poor example to pick.
I agree it's a poor example and Ubuntu's Unity is yet another one because they don't cooperate well ether. Nevertheless all these are user interfaces based on GNOME technology. They are not default and seriously shouldn't be
gnome-shell *is* the default gnome user interface starting with gnome3.
Am Sonntag, den 23.01.2011, 20:01 +0100 schrieb drago01:
On Sun, Jan 23, 2011 at 7:19 PM, Christoph Wickert christoph.wickert@googlemail.com wrote:
Am Sonntag, den 23.01.2011, 22:42 +0530 schrieb Rahul Sundaram:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME 3. Moblin upstream seems only interested in being a complete OS and haven't cooperated well with other projects which want to include Moblin as a alternative UI in their distributions. Conman, trademark shenanigans etc. I understand the point you are trying to make but Moblin is really a poor example to pick.
I agree it's a poor example and Ubuntu's Unity is yet another one because they don't cooperate well ether. Nevertheless all these are user interfaces based on GNOME technology. They are not default and seriously shouldn't be
gnome-shell *is* the default gnome user interface starting with gnome3.
I didn't claim something different. I said that *Unity and Moblin* are not default, but regardless of what is default, we shouldn't force users to install something they ether don't want to use or cannot even use.
Regards, Christoph
On Sun, 2011-01-23 at 22:42 +0530, Rahul Sundaram wrote:
On 01/23/2011 09:58 PM, Christoph Wickert wrote:
Also keep in mind that there are other "first-class desktop environment". Moblin is just as much a GNOME based first-class desktop environment as gnome-shell, just for a different use-case (Netbooks).
I don't think that's the case. GNOME Shell is a integral part of GNOME 3. Moblin upstream seems only interested in being a complete OS and haven't cooperated well with other projects which want to include Moblin as a alternative UI in their distributions. Conman, trademark shenanigans etc. I understand the point you are trying to make but Moblin is really a poor example to pick.
I can cite Unity, if you think it would help.
(runs away laughing maniacally)
On Sat, Jan 22, 2011 at 8:16 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Jan 22, 2011 at 7:05 PM, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
That is a good point. We should perhaps add a gnome-session -> gnome-shell dependency.
Please don't. There's a lot of devices that can't run gnome-shell but can run the gnome 2 configuration perfectly. With dependencies like that on devices with small amounts of space you end up with a lot of extra stuff you don't want or need.
gnome-shell should not end up being a space problem, if it is you'd be worried where the user is supposed to store his/here data ...
On Sat, Jan 22, 2011 at 7:45 PM, drago01 drago01@gmail.com wrote:
On Sat, Jan 22, 2011 at 8:16 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Sat, Jan 22, 2011 at 7:05 PM, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
That is a good point. We should perhaps add a gnome-session -> gnome-shell dependency.
Please don't. There's a lot of devices that can't run gnome-shell but can run the gnome 2 configuration perfectly. With dependencies like that on devices with small amounts of space you end up with a lot of extra stuff you don't want or need.
gnome-shell should not end up being a space problem, if it is you'd be worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything extra removes space for user data. And you could have a different device for /home anyway
Peter
Peter Robinson (pbrobinson@gmail.com) said:
gnome-shell should not end up being a space problem, if it is you'd be worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything extra removes space for user data. And you could have a different device for /home anyway
An XO-1 is a special-purpose device that is probably best served by a special-purpose OS in any case, IMO.
Bill
On Mon, Jan 24, 2011 at 5:38 PM, Bill Nottingham notting@redhat.com wrote:
Peter Robinson (pbrobinson@gmail.com) said:
gnome-shell should not end up being a space problem, if it is you'd be worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything extra removes space for user data. And you could have a different device for /home anyway
An XO-1 is a special-purpose device that is probably best served by a special-purpose OS in any case, IMO.
we've had that discussion, please go and read back through the list archives.
Peter
Peter Robinson (pbrobinson@gmail.com) said:
gnome-shell should not end up being a space problem, if it is you'd be worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything extra removes space for user data. And you could have a different device for /home anyway
An XO-1 is a special-purpose device that is probably best served by a special-purpose OS in any case, IMO.
we've had that discussion, please go and read back through the list archives.
Sure, but compare the space used by gnome-shell + mutter, vs the space used by xorg-x11-drivers and its dependencies, or all the other kernel modules that don't serve a purpose on a hardware platform like XO.
Bill
On Mon, Jan 24, 2011 at 6:06 PM, Bill Nottingham notting@redhat.com wrote:
Peter Robinson (pbrobinson@gmail.com) said:
gnome-shell should not end up being a space problem, if it is you'd be worried where the user is supposed to store his/here data ...
On something like an XO-1 where it only has 1gb of storage anything extra removes space for user data. And you could have a different device for /home anyway
An XO-1 is a special-purpose device that is probably best served by a special-purpose OS in any case, IMO.
we've had that discussion, please go and read back through the list archives.
Sure, but compare the space used by gnome-shell + mutter, vs the space used by xorg-x11-drivers and its dependencies, or all the other kernel modules that don't serve a purpose on a hardware platform like XO.
Yes, I agree wholeheartedly, but that's not what I'm asking for. I'm asking that gnome 2 desktop, that works very well in the non 3D desktop space like the XO, not to be coupled with gnome-shell / gnome 3 dependencies :-) nothing more than that.
Peter
Am Samstag, den 22.01.2011, 14:05 -0500 schrieb Matthias Clasen:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
That is a good point. We should perhaps add a gnome-session -> gnome-shell dependency.
Please don't. GDM already requires gnome-session and with gnome-shell and it's deps the Xfce spin would be way over CD size.
Regards, Christoph
On Sun, Jan 23, 2011 at 3:10 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/23/2011 08:33 PM, Christoph Wickert wrote:
Please don't. GDM already requires gnome-session and with gnome-shell and it's deps the Xfce spin would be way over CD size.
Any particular reason, Xfce spin is not using a different DM?
Both Sugar and MeeGo use GDM as well because they both have dependencies on gtk and other similar deps to gnome so you don't pull in more deps, and its also the best supported.
Peter
Am Sonntag, den 23.01.2011, 20:40 +0530 schrieb Rahul Sundaram:
On 01/23/2011 08:33 PM, Christoph Wickert wrote:
Please don't. GDM already requires gnome-session and with gnome-shell and it's deps the Xfce spin would be way over CD size.
Any particular reason, Xfce spin is not using a different DM?
Because there is no good alternative: * SLIM has problems with ConsoleKit and is dead upstream * LXDM is does not offer a keyboard selection and is broken in many ways, too. * Light-DM is not yet packaged but also kind of broken
Regards, Christoph
On 01/23/2011 09:35 PM, Christoph Wickert wrote:
* Light-DM is not yet packaged but also kind of broken
Would be useful to know what is broken. My understanding is that Ubuntu (and variants) are keen on using this as a replacement for GDM (http://mail.gnome.org/archives/desktop-devel-list/2010-October/msg00226.html) and I would have expected it to be functional. Perhaps the way forward for the "lighter" desktop environments is to switch to something like this.
Rahul
just curious, after gnome-shell starts, should i see a network manager icon somewhere? because the internet connection fails here, by default.
On Sun, Jan 23, 2011 at 16:03:13 +0100, Christoph Wickert christoph.wickert@googlemail.com wrote:
Please don't. GDM already requires gnome-session and with gnome-shell and it's deps the Xfce spin would be way over CD size.
Note that live spins should be getting back some space (probably about 50 MB for CD size images) this release as the xz stuff is coming together. I have already had a successful test fo a spin using xz and have asked nirik to start using xz for the nightly composes. So hopefully they'll be a noticeable drop in spin sizes in the next couple of days.
Am Sonntag, den 23.01.2011, 09:53 -0600 schrieb Bruno Wolff III:
On Sun, Jan 23, 2011 at 16:03:13 +0100, Christoph Wickert christoph.wickert@googlemail.com wrote:
Please don't. GDM already requires gnome-session and with gnome-shell and it's deps the Xfce spin would be way over CD size.
Note that live spins should be getting back some space (probably about 50 MB for CD size images) this release as the xz stuff is coming together. I have already had a successful test fo a spin using xz and have asked nirik to start using xz for the nightly composes. So hopefully they'll be a noticeable drop in spin sizes in the next couple of days.
Glad to hear that, but it's not really a solution. In the past we had to reduce the number of applications with every release because the dependency footprint became worse and worse. Now we cannot even ship gnumeric in the Xfce spin any longer. I am pretty sure our users don't want us to spend the new space with an additional desktop they cannot / don't want use.
BTW: FESCo started an effort to cut excessive dependencies. Looking at https://bugzilla.redhat.com/showdependencytree.cgi?id=661442 you will see that our GNOME maintainers are very unresponsive to the bugs we file.
Regards, Christoph
On Sun, Jan 23, 2011 at 17:17:38 +0100, Christoph Wickert christoph.wickert@googlemail.com wrote:
Glad to hear that, but it's not really a solution. In the past we had to reduce the number of applications with every release because the dependency footprint became worse and worse. Now we cannot even ship gnumeric in the Xfce spin any longer. I am pretty sure our users don't want us to spend the new space with an additional desktop they cannot / don't want use.
It buys time. In this case I think it makes sense to have a dependency for two release to help people upgrading. After that I would expect the dependency to be dropped as people should have already upgraded or be doing fresh installs, so that they have gnome shell.
On Sun, 2011-01-23 at 17:17 +0100, Christoph Wickert wrote:
Glad to hear that, but it's not really a solution. In the past we had to reduce the number of applications with every release because the dependency footprint became worse and worse. Now we cannot even ship gnumeric in the Xfce spin any longer. I am pretty sure our users don't want us to spend the new space with an additional desktop they cannot / don't want use.
The only way to avoid this continuing slide is to find somebody who is willing to work on language packs.
Am Montag, den 24.01.2011, 09:13 -0500 schrieb Matthias Clasen:
On Sun, 2011-01-23 at 17:17 +0100, Christoph Wickert wrote:
Glad to hear that, but it's not really a solution. In the past we had to reduce the number of applications with every release because the dependency footprint became worse and worse. Now we cannot even ship gnumeric in the Xfce spin any longer. I am pretty sure our users don't want us to spend the new space with an additional desktop they cannot / don't want use.
The only way to avoid this continuing slide is to find somebody who is willing to work on language packs.
What language packs? AFAICS it's mostly input methods and I'm afraid we cannot exclude people here. Therefor cutting the dependency bload becomes more important. If you look at the depchain tracker you will see that some of the deps are not serving any purpose and are just wrong. I'd appreciate if people looked at the bugs we file.
Regards, Christoph
On Sun, 2011-01-23 at 16:03 +0100, Christoph Wickert wrote:
Am Samstag, den 22.01.2011, 14:05 -0500 schrieb Matthias Clasen:
On Sat, 2011-01-22 at 12:43 -0600, Bruno Wolff III wrote:
On Sat, Jan 22, 2011 at 10:51:20 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Sat, 2011-01-22 at 17:44 +0200, cornel panceac wrote:
oh, but should it start panels? or at least the gnomeshell?
Yes, it starts gnome-shell, unless your system is not capable of running it, in which case it starts gnome-panel+metacity.
I did a yum upgrade from F14 to rawhide a month or so ago and have been doing contunuous updates since then. Nothing seems to have dragged in gnome-shell. It's probably worth thinking about a way to it installed for people doing yum upgrades from F13 or F14. I am not sure if using preupgrade has the same issue or not.
That is a good point. We should perhaps add a gnome-session -> gnome-shell dependency.
Please don't. GDM already requires gnome-session and with gnome-shell and it's deps the Xfce spin would be way over CD size.
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
On 01/24/2011 07:41 PM, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
What about gnome-themes-standard? I had to install the package manually after a yum upgrade from Fedora 14
Rahul
On Mon, 2011-01-24 at 21:18 +0530, Rahul Sundaram wrote:
On 01/24/2011 07:41 PM, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
What about gnome-themes-standard? I had to install the package manually after a yum upgrade from Fedora 14
I've asked Ray to sort out theme dependencies.
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
Dne 25.1.2011 07:59, Adam Williamson napsal(a):
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I would suggest just to give up. Dependencies in RPM packages in Fedora haven't meant anything for a long time already. Improvements are ignored (am I allowed to say Suggests/Recommends here?), bugs against broken dependencies WONTFIXed or ignored as well (try to run Rawhide and upgrade just some packages and do it repeatedly for a long time ... you will collect a lot of nice WONTFIXes).
They mean only whatever form of abuse anybody treats them to currently.
Matěj
On Tue, Jan 25, 2011 at 8:34 AM, Matej Cepl mcepl@redhat.com wrote:
Dne 25.1.2011 07:59, Adam Williamson napsal(a):
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I would suggest just to give up. Dependencies in RPM packages in Fedora haven't meant anything for a long time already. Improvements are ignored (am I allowed to say Suggests/Recommends here?), bugs against broken dependencies WONTFIXed or ignored as well (try to run Rawhide and upgrade just some packages and do it repeatedly for a long time ... you will collect a lot of nice WONTFIXes).
Actually if your speaking for the Red Hat desktop team I agree with your point because its clear they have an "I'm right Jack, everything for gnome shell attitude so screw everyone else" and it seems from my point of view that they clearly couldn't give a stuff about anyone else but themselves. And that attitude sucks and I'm getting sick of going around my packages and spending a lot of time cleaning up the mess of when one of that team comes and makes a mess all over the place.
In terms of dependencies for gnome 3 you may be right but for every other part of the distribution you are completely wrong, at least on this space time continuum. There are quite a number of people fixing dependency problems and its attitudes like this that really piss me off. We got finally rid of perl in the last release which regained quite a bit of space for just about all spins for a net win. The Mobility SIG (mostly me but others as well), the server SIG and the AOS/JeOS/Virt SIG have been working consistently for a long time (me for 3 or more years) to try and fix these issues so that is why I'm getting a little upset on the attitude.
Just because in your world you have terabytes of space and internet connections in the tens or even hundreds of megs a second there's a LOT of places in the world that don't have that luxury or have to pay a lot (like multiple dollars per gig of download) for bandwidth so saving a 100 meg here and there is worthwhile. I've spoken to a lot of people that are moving from Fedora to Debian and other distros for this exact reason. Another classic example of this is updates to openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o since the release of F-14 for such critical bugs as "background isn't transparent" [1] surely these could be bundled together once a month or so (I thought there was suppose to be a policy about this but I can't find it).
Peter
They mean only whatever form of abuse anybody treats them to currently.
[1] https://admin.fedoraproject.org/updates/openoffice.org-3.3.0-20.1.fc14
On 01/25/2011 04:11 PM, Peter Robinson wrote:
this exact reason. Another classic example of this is updates to openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o since the release of F-14 for such critical bugs as "background isn't transparent" [1] surely these could be bundled together once a month or so (I thought there was suppose to be a policy about this but I can't find it).
There isn't any such policy suggesting or requiring bundling of bug fixes and trying to mandate it via policy doesn't really seem feasible. We could talk to the maintainers in question and understand what happened first before trying to stop it. If it isn't a one off problem, then it makes sense to discuss it in the broader context.
Rahul
On Tue, Jan 25, 2011 at 11:19 AM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 04:11 PM, Peter Robinson wrote:
this exact reason. Another classic example of this is updates to openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o since the release of F-14 for such critical bugs as "background isn't transparent" [1] surely these could be bundled together once a month or so (I thought there was suppose to be a policy about this but I can't find it).
There isn't any such policy suggesting or requiring bundling of bug fixes and trying to mandate it via policy doesn't really seem feasible. We could talk to the maintainers in question and understand what happened first before trying to stop it. If it isn't a one off problem, then it makes sense to discuss it in the broader context.
The number of updates in a stable release has been discussed, at length. There was even discussion of implementing a policy for it but it clearly was never done.
Peter
On 01/25/2011 05:04 PM, Peter Robinson wrote:
The number of updates in a stable release has been discussed, at length. There was even discussion of implementing a policy for it but it clearly was never done
A policy does exist but says nothing about bundling bug fixes
http://fedoraproject.org/wiki/Updates_Policy
Rahul
On 01/25/11 06:59, Rahul Sundaram wrote:
On 01/25/2011 05:04 PM, Peter Robinson wrote:
The number of updates in a stable release has been discussed, at length. There was even discussion of implementing a policy for it but it clearly was never done
A policy does exist but says nothing about bundling bug fixes
http://fedoraproject.org/wiki/Updates_Policy
Rahul
Two related policies are kind-of/sort-of there. The document does state that "Package maintainers MUST: {...} Avoid updates that are trivial or don't affect any Fedora users." The tough question is to define "trivial", and perhaps there may need to be some threshold of expected affected users before a patch is rolled out to everyone.
There also is the philosophy for stable releases that "The update rate for any given release should drop off over time," which presumes that as bugfixes are added less future ones should be needed. (Not that everyone is working on the next release, which probably is also true.)
2011/1/25 Peter Robinson pbrobinson@gmail.com
On Tue, Jan 25, 2011 at 11:19 AM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 04:11 PM, Peter Robinson wrote:
this exact reason. Another classic example of this is updates to openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o since the release of F-14 for such critical bugs as "background isn't transparent" [1] surely these could be bundled together once a month or so (I thought there was suppose to be a policy about this but I can't find it).
There isn't any such policy suggesting or requiring bundling of bug fixes and trying to mandate it via policy doesn't really seem feasible. We could talk to the maintainers in question and understand what happened first before trying to stop it. If it isn't a one off problem, then it makes sense to discuss it in the broader context.
The number of updates in a stable release has been discussed, at length. There was even discussion of implementing a policy for it but it clearly was never done.
another thing that can be done is somehow encouraging the creation of delta rpms, especially for big packages (like ooo).
2011/1/25 Rahul Sundaram metherid@gmail.com
On 01/25/2011 05:51 PM, cornel panceac wrote:
another thing that can be done is somehow encouraging the creation of delta rpms, especially for big packages (like ooo).
We already do generate deltarpm. There was a bug in the process which has been fixed.
thank you
On Tue, 2011-01-25 at 10:41 +0000, Peter Robinson wrote:
Actually if your speaking for the Red Hat desktop team I agree with your point because its clear they have an "I'm right Jack, everything for gnome shell attitude so screw everyone else" and it seems from my point of view that they clearly couldn't give a stuff about anyone else but themselves. And that attitude sucks and I'm getting sick of going around my packages and spending a lot of time cleaning up the mess of when one of that team comes and makes a mess all over the place.
Is that really necessary ? Can we have at least one mailing list where we refrain from name-calling and accusatory language, please ?
In terms of dependencies for gnome 3 you may be right but for every other part of the distribution you are completely wrong, at least on this space time continuum. There are quite a number of people fixing dependency problems and its attitudes like this that really piss me off. We got finally rid of perl in the last release which regained quite a bit of space for just about all spins for a net win. The Mobility SIG (mostly me but others as well), the server SIG and the AOS/JeOS/Virt SIG have been working consistently for a long time (me for 3 or more years) to try and fix these issues so that is why I'm getting a little upset on the attitude.
The desktop team has not brought perl back. It is getting pulled in by cups, indirectly. Please be at least a little more careful with your accusations. Thanks.
On Tue, Jan 25, 2011 at 2:30 PM, Matthias Clasen mclasen@redhat.com wrote:
On Tue, 2011-01-25 at 10:41 +0000, Peter Robinson wrote:
Actually if your speaking for the Red Hat desktop team I agree with your point because its clear they have an "I'm right Jack, everything for gnome shell attitude so screw everyone else" and it seems from my point of view that they clearly couldn't give a stuff about anyone else but themselves. And that attitude sucks and I'm getting sick of going around my packages and spending a lot of time cleaning up the mess of when one of that team comes and makes a mess all over the place.
Is that really necessary ? Can we have at least one mailing list where we refrain from name-calling and accusatory language, please ?
In terms of dependencies for gnome 3 you may be right but for every other part of the distribution you are completely wrong, at least on this space time continuum. There are quite a number of people fixing dependency problems and its attitudes like this that really piss me off. We got finally rid of perl in the last release which regained quite a bit of space for just about all spins for a net win. The Mobility SIG (mostly me but others as well), the server SIG and the AOS/JeOS/Virt SIG have been working consistently for a long time (me for 3 or more years) to try and fix these issues so that is why I'm getting a little upset on the attitude.
The desktop team has not brought perl back. It is getting pulled in by cups, indirectly. Please be at least a little more careful with your accusations. Thanks.
I wasn't accusing the desktop team of bringing back perl, I'm well aware where the dependency lies (plus net-snmp and others). It was the point above the one you cut out where one of the desktop team said "I would suggest just to give up. Dependencies in RPM packages in Fedora haven't meant anything for a long time already."
Peter
On 01/25/2011 08:12 PM, Peter Robinson wrote:
I wasn't accusing the desktop team of bringing back perl, I'm well aware where the dependency lies (plus net-snmp and others). It was the point above the one you cut out where one of the desktop team said "I would suggest just to give up. Dependencies in RPM packages in Fedora haven't meant anything for a long time already."
I think you are missing context there. I read it as frustration from someone who works as a full time bug triager for that team rather than a serious suggestion. Let's stick to the technical discussions.
Rahul
Dne 25.1.2011 15:44, Rahul Sundaram napsal(a):
I think you are missing context there. I read it as frustration from someone who works as a full time bug triager for that team rather than a serious suggestion. Let's stick to the technical discussions.
Yes, sorry for my sarcasm not being obvious enough. However, I would strongly disagree with accusing only desktop team of this. IMHO, whole Fedora is to be blamed for this in all its parts.
Matěj
Dne 25.1.2011 11:41, Peter Robinson napsal(a):
In terms of dependencies for gnome 3 you may be right but for every other part of the distribution you are completely wrong, at least on this space time continuum. There are quite a number of people fixing dependency problems and its attitudes like this that really piss me off.
Try that experiment with Rawhide (updating just individual packages when you feel like you need more modern version of the particular pacakge; the trick is never to run unqualified yum upgrade for whole system).
for 3 or more years) to try and fix these issues so that is why I'm getting a little upset on the attitude.
Just to emphasize, I used to use Debian for many years, so I completely don't agree with the level of brokeness all Fedora packages requirements have IMHO.
openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o since the release of F-14 for such critical bugs as "background isn't transparent" [1] surely these could be bundled together once a month or so (I thought there was suppose to be a policy about this but I can't find it).
Fortunately, presto makes miracles about OpenOffice, but again only if you regularly update complete distro.
Matěj
On Tue, Jan 25, 2011 at 4:28 PM, Matej Cepl mcepl@redhat.com wrote:
Dne 25.1.2011 11:41, Peter Robinson napsal(a):
In terms of dependencies for gnome 3 you may be right but for every other part of the distribution you are completely wrong, at least on this space time continuum. There are quite a number of people fixing dependency problems and its attitudes like this that really piss me off.
Try that experiment with Rawhide (updating just individual packages when you feel like you need more modern version of the particular pacakge; the trick is never to run unqualified yum upgrade for whole system).
for 3 or more years) to try and fix these issues so that is why I'm getting a little upset on the attitude.
Just to emphasize, I used to use Debian for many years, so I completely don't agree with the level of brokeness all Fedora packages requirements have IMHO.
openoffice. There have been 10 updates @ 200Mb odd MB each for oo.o since the release of F-14 for such critical bugs as "background isn't transparent" [1] surely these could be bundled together once a month or so (I thought there was suppose to be a policy about this but I can't find it).
Fortunately, presto makes miracles about OpenOffice, but again only if you regularly update complete distro.
There's places where presto doesn't work well. And until recently it didn't work at all on openoffce because of the size. And in cases where you get lots of updates in a short period of time your out of luck. Which in a case where bandwidth is expensive you might not upgrade every time a patch comes our your in the situation where you have to download the whole thing. My point was that the kernel team for example commit a series of patches for a number of bugs and push a new version occasionally as opposed to pushing out multiple large updates to fix each corner case bug.
Peter
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell. GNOME Panel is a particularly bad place to have that additional dependency because if I have a system that doesn't support GNOME Shell or I just don't prefer to use it yet and I am only using the GNOME Panel, it doesn't make sense to keep GNOME Shell installed.
Rahul
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is what the fallback supposed to be), to save a few MB of disk space for some users that care about every single MB on their hard drive.
On Tue, Jan 25, 2011 at 1:34 PM, drago01 drago01@gmail.com wrote:
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is what the fallback supposed to be), to save a few MB of disk space for some users that care about every single MB on their hard drive.
I've not ever asked for a "degraded user experience" what I'm asking for it not to put dependency hacks to fix a problem that should be fixed in some other way. Please don't put this out of context.
Peter
On Tue, Jan 25, 2011 at 2:39 PM, Peter Robinson pbrobinson@gmail.com wrote:
On Tue, Jan 25, 2011 at 1:34 PM, drago01 drago01@gmail.com wrote:
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is what the fallback supposed to be), to save a few MB of disk space for some users that care about every single MB on their hard drive.
I've not ever asked for a "degraded user experience" what I'm asking for it not to put dependency hacks to fix a problem that should be fixed in some other way. Please don't put this out of context.
I have replied to *Rahul's* mail not yours where he said "A upgrade needn't pull in GNOME Shell" (I didn't even mention how this should be done but having the user installing it by hand post upgrade is just wrong).
So please don't put this out of context.
On Tue, 2011-01-25 at 13:39 +0000, Peter Robinson wrote:
I've not ever asked for a "degraded user experience" what I'm asking for it not to put dependency hacks to fix a problem that should be fixed in some other way. Please don't put this out of context.
I've yet to see a proposal for what that 'other way' would be. I'm open to dropping the dependency when such a proposal surfaces...
On 01/25/2011 07:04 PM, drago01 wrote
No users upgrading should not get a degraded user experience (that is what the fallback supposed to be), to save a few MB of disk space for some users that care about every single MB on their hard drive.
That is a gross mischaracterization of people are expecting in this discussion. For one, the fallback mode provides pretty much the same experience as before the upgrade and doesn't degrade it. I don't care about every single MB on my hard drive however randomly adding artificial dependencies to packages cannot be the solution for providing the upgrade experience you want to provide. If you want to tackle that problem, it is a much bigger one (defaults change, new packages get added, some cleanup might be needed etc) and needs to be handled differently.
Rahul
On Tue, Jan 25, 2011 at 19:31:51 +0530, Rahul Sundaram metherid@gmail.com wrote:
That is a gross mischaracterization of people are expecting in this discussion. For one, the fallback mode provides pretty much the same experience as before the upgrade and doesn't degrade it. I don't care
I think you want the future tense there. The fallback mode doesn't work currently if you don't have gnome-shell installed.
about every single MB on my hard drive however randomly adding artificial dependencies to packages cannot be the solution for providing the upgrade experience you want to provide. If you want to tackle that problem, it is a much bigger one (defaults change, new packages get added, some cleanup might be needed etc) and needs to be handled differently.
I believe there was a claim that proper obsoletes and provides could potentially handle upgrades from older Fedora releases while not using hard dependencies. I did not see a detailed proposal on how this would be done though.
On 01/25/2011 07:54 PM, Bruno Wolff III wrote:
On Tue, Jan 25, 2011 at 19:31:51 +0530, Rahul Sundaram wrote:
That is a gross mischaracterization of people are expecting in this discussion. For one, the fallback mode provides pretty much the same experience as before the upgrade and doesn't degrade it. I don't care
I think you want the future tense there. The fallback mode doesn't work currently if you don't have gnome-shell installed.
That will be fixed before release. So the discussion has to take that into account.
Rahul
On Tue, 2011-01-25 at 14:34 +0100, drago01 wrote:
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is what the fallback supposed to be), to save a few MB of disk space for some users that care about every single MB on their hard drive.
I think we should ensure the supported upgrade methods - installer upgrade, preupgrade - do the right thing somehow, but yum doesn't have to.
If there isn't a mechanism to deal with this situation via anaconda, well, it seems like a deficiency in our upgrade process which should be remedied, not something to work around by abusing package dependencies. If we really have to work around it, though, there must be a better workaround than making up dependencies for gnome-shell; I don't recall who suggested it, but something involving a meta-package should work more elegantly.
Tue, Jan 25, 2011 at 6:57 PM, Adam Williamson awilliam@redhat.com wrote:
On Tue, 2011-01-25 at 14:34 +0100, drago01 wrote:
On Tue, Jan 25, 2011 at 12:24 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell.
No users upgrading should not get a degraded user experience (that is what the fallback supposed to be), to save a few MB of disk space for some users that care about every single MB on their hard drive.
I think we should ensure the supported upgrade methods - installer upgrade, preupgrade - do the right thing somehow, but yum doesn't have to.
If there isn't a mechanism to deal with this situation via anaconda, well, it seems like a deficiency in our upgrade process which should be remedied, not something to work around by abusing package dependencies. If we really have to work around it, though, there must be a better workaround than making up dependencies for gnome-shell; I don't recall who suggested it, but something involving a meta-package should work more elegantly.
My understanding of the anaconda upgrade process is that it installed any missing packages from an installed group (such as gnome-desktop), but I may be misinformed there.
Peter
On Tue, 2011-01-25 at 16:54 +0530, Rahul Sundaram wrote:
On 01/25/2011 12:29 PM, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically. A upgrade needn't pull in GNOME Shell. GNOME Panel is a particularly bad place to have that additional dependency because if I have a system that doesn't support GNOME Shell or I just don't prefer to use it yet and I am only using the GNOME Panel, it doesn't make sense to keep GNOME Shell installed.
No, it is really required that an upgrade gives you the intended experience of the release you are upgrading to. We are working very hard to make GNOME 3 good, and would like people to actually get whats on the label when the upgrade to F15. I don't want to see reactions like
'Hey, I upgraded to F15 and really like that new GNOME 3 experience'
'Really ? I just upgraded, and it looks the same it always did :-('
On 01/25/2011 08:03 PM, Matthias Clasen wrote
No, it is really required that an upgrade gives you the intended experience of the release you are upgrading to. We are working very hard to make GNOME 3 good, and would like people to actually get whats on the label when the upgrade to F15. I don't want to see reactions like
'Hey, I upgraded to F15 and really like that new GNOME 3 experience'
'Really ? I just upgraded, and it looks the same it always did :-('
Add a note to the release notes or handle it in a different manner. GNOME Shell is a alternative to GNOME Panel. Adding a dependency from the latter to the former doesn't make any sense. It is a misuse of dependency mechanism.
Rahul
On Tue, Jan 25, 2011 at 3:37 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 08:03 PM, Matthias Clasen wrote
No, it is really required that an upgrade gives you the intended experience of the release you are upgrading to. We are working very hard to make GNOME 3 good, and would like people to actually get whats on the label when the upgrade to F15. I don't want to see reactions like
'Hey, I upgraded to F15 and really like that new GNOME 3 experience'
'Really ? I just upgraded, and it looks the same it always did :-('
Add a note to the release notes or handle it in a different manner. GNOME Shell is a alternative to GNOME Panel. Adding a dependency from the latter to the former doesn't make any sense. It is a misuse of dependency mechanism.
It is not indented as alternative to in the way you might think it is just a fallback for older hardware and/or crappy drivers. Hence the name "fallback". If you really care that much about it suggest a better way (no a release note entry is not it).
On 01/25/2011 08:17 PM, drago01 wrote:
It is not indented as alternative to in the way you might think it is just a fallback for older hardware and/or crappy drivers. Hence the name "fallback".
Call it whatever you want. It is a alternative in the sense that you cannot run both at the same time. There is absolutely no technical reason why GNOME Panel would require GNOME Shell as a dependency.
If you really care that much about it suggest a better way (no a release note entry is not it)
If you are going to dismiss suggestions without any explanation, why would I bother? If you insist that a artificial dependency is the right way, then not much can be done about it.
Rahul
On Tue, Jan 25, 2011 at 3:48 PM, Rahul Sundaram metherid@gmail.com wrote:
On 01/25/2011 08:17 PM, drago01 wrote:
It is not indented as alternative to in the way you might think it is just a fallback for older hardware and/or crappy drivers. Hence the name "fallback".
Call it whatever you want. It is a alternative in the sense that you cannot run both at the same time. There is absolutely no technical reason why GNOME Panel would require GNOME Shell as a dependency.
If you really care that much about it suggest a better way (no a release note entry is not it)
If you are going to dismiss suggestions without any explanation, why would I bother?
I though it was obvious that requiring the user to go read the release notes to get the expected user experience is just wrong.
If you insist that a artificial dependency is the right way, then not much can be done about it.
It isn't ideal but the costs are few megabytes of disk space versus the benefit of a better upgrade experience. Unless we have a better way (which we should have to handle cases like this), I'd take that cost.
On 01/25/2011 08:27 PM, drago01 wrote:
I though it was obvious that requiring the user to go read the release notes to get the expected user experience is just wrong.
I thought It was obvious that adding a dependency from GNOME Panel to GNOME Shell is just wrong too. It is natural that GNOME Shell developers want to provide that experience but that doesn't mean just adding a dependency somewhere randomly is the right idea. If users don't read the release notes, they are missing a number of changes in the user experience all the time. For instance, we change the default or add additional apps to the desktop group often and the users are missing that.
If you insist that a artificial dependency is the right way, then not much can be done about it.
It isn't ideal but the costs are few megabytes of disk space versus the benefit of a better upgrade experience. Unless we have a better way (which we should have to handle cases like this), I'd take that cost
Others have explained what problems they are trying to solve other than disk space already.
Rahul
Rahul Sundaram (metherid@gmail.com) said:
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel is GNOME), and they upgrade, they'll get the current version of GNOME. And that's GNOME Shell.
Bill
On Tue, Jan 25, 2011 at 10:01, Bill Nottingham notting@redhat.com wrote:
Rahul Sundaram (metherid@gmail.com) said:
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel is GNOME), and they upgrade, they'll get the current version of GNOME. And that's GNOME Shell.
Thank you for repeating this. It appears to not be common knowledge--in this conversation--that gnome-panel is deprecated and, essentially, in deep maintenance mode. GNOME Shell is the UI of GNOME 3 and you only land on the fallback gnome-panel if your hardware doesn't support it or, if the detection logic doesn't guess your hardware correctly, you force GNOME in to fallback mode (modulo this UI being created before the release).
On 01/25/2011 09:31 PM, Bill Nottingham wrote:
How so? When we included KDE 4, we didn't leave users on KDE 3 on upgrade.
KDE 4 components obsoleted the KDE 3 equivalents. GNOME wants to provide both GNOME Shell and GNOME Panel for Fedora 15 users. So not quite the same situation.
Similarly, when a user has GNOME installed (and yes, the gnome-panel is GNOME), and they upgrade, they'll get the current version of GNOME. And that's GNOME Shell.
I might agree with the end result. Disagree with the implementation.
Rahul
Does not this discussion belong on [1] were the Red Hat Desktop Team resides....
JBG
On Tue, Jan 25, 2011 at 4:01 PM, Bill Nottingham notting@redhat.com wrote:
Rahul Sundaram (metherid@gmail.com) said:
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on upgra
Similarly, when a user has GNOME installed (and yes, the gnome-panel is GNOME), and they upgrade, they'll get the current version of GNOME. And that's GNOME Shell.
I mostly agree but the difference in this case there is essentially a fork as the newer interface won't work on all devices that the old one previously did so you have circumstances where it just won't work or will crash horribly even on devices that are suppose to work (and to see that go and check the abrt bugs against mutter that say "just crashed when I tried gnome-shell" and the, in some cases, 100s of dupes). I see them every day when they hit my inbox as I originally packaged mutter and most of the gnome shell components for moblin (and now meego) so I'm well aware of the problems there are. Where as KDE 3 - 4 didn't have hardware incompatibilities and gnome has said they'll maintain both of the interfaces.
Peter
Peter Robinson (pbrobinson@gmail.com) said:
I mostly agree but the difference in this case there is essentially a fork as the newer interface won't work on all devices that the old one previously did so you have circumstances where it just won't work or will crash horribly even on devices that are suppose to work (and to see that go and check the abrt bugs against mutter that say "just crashed when I tried gnome-shell" and the, in some cases, 100s of dupes). I see them every day when they hit my inbox as I originally packaged mutter and most of the gnome shell components for moblin (and now meego) so I'm well aware of the problems there are. Where as KDE 3
- 4 didn't have hardware incompatibilities and gnome has said they'll
maintain both of the interfaces.
That doesn't mean the interfaces are separate products, or need to be seperable components. Certainly not on upgrade.
Bill
On Tue, Jan 25, 2011 at 4:01 PM, Bill Nottingham notting@redhat.com wrote:
Rahul Sundaram (metherid@gmail.com) said:
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel is GNOME), and they upgrade, they'll get the current version of GNOME. And that's GNOME Shell.
Unless of course they have no gnome-shell-capable hardware which may not be insignificant numbers!
On Tue, Jan 25, 2011 at 6:31 PM, mike cloaked mike.cloaked@gmail.com wrote:
On Tue, Jan 25, 2011 at 4:01 PM, Bill Nottingham notting@redhat.com wrote:
Rahul Sundaram (metherid@gmail.com) said:
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
I think users upgrading from a previous release can continue to get the fallback mode unless they do a group installation or try to install GNOME Shell specifically.
How so? When we included KDE 4, we didn't leave users on KDE 3 on upgrade.
Similarly, when a user has GNOME installed (and yes, the gnome-panel is GNOME), and they upgrade, they'll get the current version of GNOME. And that's GNOME Shell.
Unless of course they have no gnome-shell-capable hardware which may not be insignificant numbers!
In that case gnome-session will detect that and start the fallback (still no valid case against it being installed).
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option. The 'natural' place for the dependency would be gnome-session. I have put it in gnome-panel to help other spins who use gdm and might not want the extra baggage - and see how warmly probinson thanked me for it :-(
On Tue, Jan 25, 2011 at 2:35 PM, Matthias Clasen mclasen@redhat.com wrote:
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option. The 'natural' place for the dependency would be gnome-session. I have put it in gnome-panel to help other spins who use gdm and might not want the extra baggage - and see how warmly probinson thanked me for it :-(
But gnome-panel is the old way. It means anyone who can't use gnome-3 gets it and all its dependencies anyway. Its not a direct attack on you but there must be a better way to provide a "seemless upgrade" using comps groups or something similar.
Peter
On 01/25/2011 08:35 AM, Matthias Clasen wrote:
Make a better proposal then. Just doing nothing is not an option.
Why not? Please point to the Fedora policy that says this.
Ian Pilcher (arequipeno@gmail.com) said:
On 01/25/2011 08:35 AM, Matthias Clasen wrote:
Make a better proposal then. Just doing nothing is not an option.
Why not? Please point to the Fedora policy that says this.
What? We need a written policy that states 'a user that has version X of a desktop should cleanly upgrade to the next version of it properly'?
I really didn't think we needed that level of pedanticism in our policies.
Bill
On Tue, Jan 25, 2011 at 09:35:27 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option. The 'natural' place for the dependency would be gnome-session. I have put it in gnome-panel to help other spins who use gdm and might not want the extra baggage - and see how warmly probinson thanked me for it :-(
How about this for a proposal: Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel, metacity (since it needs these for fall back). I think that will do what you want. (Note there isn't a 2.9x version of metacity, so you obsoleting that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged in F13 or F14 as an update this should work.
On Tue, 2011-01-25 at 10:02 -0600, Bruno Wolff III wrote:
On Tue, Jan 25, 2011 at 09:35:27 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Mon, 2011-01-24 at 22:59 -0800, Adam Williamson wrote:
On Mon, 2011-01-24 at 09:11 -0500, Matthias Clasen wrote:
I've added the dependency to gnome-panel. That should achieve the same for gnome users on upgrade, without affecting other spins.
But it doesn't make any sense. gnome-panel does *not* require gnome-shell. We really shouldn't just go around abusing dependencies to make upgrades 'work', even if it is convenient.
Make a better proposal then. Just doing nothing is not an option. The 'natural' place for the dependency would be gnome-session. I have put it in gnome-panel to help other spins who use gdm and might not want the extra baggage - and see how warmly probinson thanked me for it :-(
How about this for a proposal: Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel, metacity (since it needs these for fall back). I think that will do what you want. (Note there isn't a 2.9x version of metacity, so you obsoleting that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a gnome-panel >= 2.90 is in F15.
Matthias Clasen (mclasen@redhat.com) said:
How about this for a proposal: Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel, metacity (since it needs these for fall back). I think that will do what you want. (Note there isn't a 2.9x version of metacity, so you obsoleting that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a gnome-panel >= 2.90 is in F15.
I checked with Seth et. al.; something like:
Obsoletes: gnome-panel < 2.90 Requires: gnome-panel >= 2.90
*will* work. (Adjust for any epochs, of course.)
Bill
On Tue, 2011-01-25 at 13:35 -0500, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
How about this for a proposal: Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel, metacity (since it needs these for fall back). I think that will do what you want. (Note there isn't a 2.9x version of metacity, so you obsoleting that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a gnome-panel >= 2.90 is in F15.
I checked with Seth et. al.; something like:
Obsoletes: gnome-panel < 2.90 Requires: gnome-panel >= 2.90
*will* work. (Adjust for any epochs, of course.)
I'll give it a try when gnome-panel 2.90 arrives
On Tue, 2011-01-25 at 12:00 -0500, Matthias Clasen wrote:
How about this for a proposal: Have gnome shell obsolete gnome-panel < 2.90 and require gnome-panel, metacity (since it needs these for fall back). I think that will do what you want. (Note there isn't a 2.9x version of metacity, so you obsoleting that gets a lot trickier.) As long as gnome-panel-2.9x isn't packaged in F13 or F14 as an update this should work.
I'm not sure that such an Obsoletes will do anything, as long as a gnome-panel >= 2.90 is in F15.
I agree, but I think the approach possibly has merit with a tweak. How about gnome-panel is renamed gnome-panel-legacy , gnome-shell obsoletes gnome-panel and requires gnome-panel-legacy ? I think that way you'd get gnome-shell on upgrade but at least would be able to remove it, and it's at least a _more_ correct description of the relationships.
(Side note: I think we might all have found things rather easier if we used a meta-package approach rather than comps; for me, one thing this discussion exposes is that things are a lot harder because comps - obviously - isn't considered by yum. If we had a 'task-gnome' metapackage which expressed what packages are required for the desired GNOME desktop experience, it'd make things a lot easier, because that could require gnome-shell , but you could always remove the task-gnome metapackage if you wanted to...people who didn't fiddle with anything would get gnome-shell on upgrade, people who fiddle with things get to keep both pieces.)
At this point I would appreciate if people would focus on generating potential solutions that work well for everyone. Until we find there is no such solution it's premature to be arguing which compromise we should make. And the discussion is getting a bit heated worrying about decisions that may not even be needed.
On 01/22/2011 10:10 AM, Matthias Clasen wrote:
On Fri, 2011-01-21 at 11:03 -0500, Clyde E. Kunkel wrote:
Should they be visible?
GNOME 3 will not start nautilus by default. Sorry, I should have probably announced this change hitting rawhide.
The startup applications menu selection has gone away also...so how do we start nautilus when gnome is loaded? Used to be able to put a startup cmd in the startup apps dialogue.
Regards, OldFart
On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkel clydekunkel7734@cox.netwrote:
The startup applications menu selection has gone away also...so how do we start nautilus when gnome is loaded? Used to be able to put a startup cmd in the startup apps dialogue.
http://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.h...
Short version: ln -s /usr/share/applications/name.desktop ~/.config/autostart
On 01/22/2011 12:53 PM, Jason D. Clinton wrote:
On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkelclydekunkel7734@cox.netwrote:
The startup applications menu selection has gone away also...so how do we start nautilus when gnome is loaded? Used to be able to put a startup cmd in the startup apps dialogue.
http://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.h...
Short version: ln -s /usr/share/applications/name.desktop ~/.config/autostart
Thanks for the suggestion. It didn't work and the discussion on this thread has gone in a different direction.
I can get a startup application for nautilus (that used to work) to execute when rawhide gnome is loaded since my home directory is shared with F14,and other RH and Fedora installations. But the desktop icons do not show up in rawhide.
Does anyone have any other workarounds?
TIA
Regards, OldFart
On Sun, 2011-01-23 at 11:17 -0500, Clyde E. Kunkel wrote:
On 01/22/2011 12:53 PM, Jason D. Clinton wrote:
On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkelclydekunkel7734@cox.netwrote:
The startup applications menu selection has gone away also...so how do we start nautilus when gnome is loaded? Used to be able to put a startup cmd in the startup apps dialogue.
http://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.h...
Short version: ln -s /usr/share/applications/name.desktop ~/.config/autostart
Thanks for the suggestion. It didn't work and the discussion on this thread has gone in a different direction.
I can get a startup application for nautilus (that used to work) to execute when rawhide gnome is loaded since my home directory is shared with F14,and other RH and Fedora installations. But the desktop icons do not show up in rawhide.
Does anyone have any other workarounds?
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is running, so do it before starting nautilus.
Matthias Clasen (mclasen@redhat.com) said:
Does anyone have any other workarounds?
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is running, so do it before starting nautilus.
If this is the sort of thing that people who have set up their desktop with icons may want, but we don't want as the normal way going forwards, why not set this key to be enabled in the gconf->gsettings migration schema, but off in the actual schema default for new installs?
Bill
On Mon, 2011-01-24 at 13:01 -0500, Bill Nottingham wrote:
Matthias Clasen (mclasen@redhat.com) said:
Does anyone have any other workarounds?
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is running, so do it before starting nautilus.
If this is the sort of thing that people who have set up their desktop with icons may want, but we don't want as the normal way going forwards, why not set this key to be enabled in the gconf->gsettings migration schema, but off in the actual schema default for new installs?
Migration just copies whatever value you had in your gconf db, it is not set up to 'inject' new values. And since the old default was 'true', few people will have it in their local db (unless they set it to false...).
On 01/24/2011 09:23 AM, Matthias Clasen wrote:
<snip>
gsettings set org.gnome.desktop.background show-desktop-icons true
Note that nautilus seems to crash when the key is changed while it is running, so do it before starting nautilus.
Many, many, many thanks!
Shouldn't this be the default? Don't most folks want desktop icons?
Regards OldFart
Am Samstag, den 22.01.2011, 11:53 -0600 schrieb Jason D. Clinton:
On Sat, Jan 22, 2011 at 09:58, Clyde E. Kunkel clydekunkel7734@cox.net wrote: The startup applications menu selection has gone away also...so how do we start nautilus when gnome is loaded? Used to be able to put a startup cmd in the startup apps dialogue.
http://specifications.freedesktop.org/autostart-spec/autostart-spec-latest.h...
Short version: ln -s /usr/share/applications/name.desktop ~/.config/autostart
1. With that 'fix' nautilus won't work correctly. 2. I don't think that opening a terminal to make a symlink is the kind of user friendly fall-back we want.
Regards, Christoph
On Sat, Jan 22, 2011 at 10:10:32 -0500, Matthias Clasen mclasen@redhat.com wrote:
On Fri, 2011-01-21 at 11:03 -0500, Clyde E. Kunkel wrote:
Should they be visible?
GNOME 3 will not start nautilus by default. Sorry, I should have probably announced this change hitting rawhide.
What about people who want to continue running (or were running) metacity. For the last week or two, none of metacity, nautilus and nautlius appear to be getting started after logging in with gdm. I have to escape back to a vt to start at least metacity and gnome-panel to be able to do anything.
It may be because I have been doing continuous upgrades, that I am seeing something different than people who do fresh rawhide installs today.
-
Adam Williamson -
Andre Robatino -
Bill Nottingham -
Bruno Wolff III -
Christoph Wickert -
Clyde E. Kunkel -
cornel panceac -
David -
drago01 -
Ian Pilcher -
Jason D. Clinton -
Jóhann B. Guðmundsson -
Matej Cepl -
Matthew Garrett -
Matthias Clasen -
mike cloaked -
Peter Robinson -
Rahul Sundaram -
Samuel Greenfeld