[opensuse-factory] repository priorities with Tumbleweed
Hi, what is the current suggestion of Greg KH to repository priorities running Tumbleweed? In the early days he suggested flat ones, over time more and more users reported (in forums) that a higher one for Tumbleweed (or even a complicated priority-hierarchy) works better. I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start. So I gave Tumbleweed a higher priority, but that did not help. Maybe I am doing something wrong? But even if my problem has nothing to do with the priorities, please think about my request: - add info on how to handle priorities on the SDB:Tumbleweed - Or even better: Add an automatism to zypper/yast that automagically sets the "right" priorities, while advanced users are still able to customize it Thanks vor Tumbleweed so far - it is great and I love it :D Thomas -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 22 June 2012 11:52, Thomas Langkamp
Hi, what is the current suggestion of Greg KH to repository priorities running Tumbleweed? In the early days he suggested flat ones, over time more and more users reported (in forums) that a higher one for Tumbleweed (or even a complicated priority-hierarchy) works better.
I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start.
So I gave Tumbleweed a higher priority, but that did not help. Maybe I am doing something wrong? But even if my problem has nothing to do with the priorities, please think about my request:
- add info on how to handle priorities on the SDB:Tumbleweed - Or even better: Add an automatism to zypper/yast that automagically sets the "right" priorities, while advanced users are still able to customize it
It's not like settings priorities was a big mystery. When two repositories have different versions of the same package... set the repository you want the packages from with a higher priority. Really, the meaning of priorities is the one you would expect. Set them as the common sense tells you to. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Fri, Jun 22, 2012 at 12:52:55PM +0200, Thomas Langkamp wrote:
Hi, what is the current suggestion of Greg KH to repository priorities running Tumbleweed? In the early days he suggested flat ones, over time more and more users reported (in forums) that a higher one for Tumbleweed (or even a complicated priority-hierarchy) works better.
I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start.
Why is this a Tumbleweed repo priority issue? It's probably just a general "the kde repo is borked" issue which I've been fighting for the past few weeks :(
So I gave Tumbleweed a higher priority, but that did not help. Maybe I am doing something wrong? But even if my problem has nothing to do with the priorities, please think about my request:
- add info on how to handle priorities on the SDB:Tumbleweed
Do not do so.
- Or even better: Add an automatism to zypper/yast that automagically sets the "right" priorities, while advanced users are still able to customize it
The "right" one for Tumbleweed is to not do it :) As you point out, changing the priority of Tumbleweed does not solve your problem, so I am very confused as to why you would think that this is even an issue here at all. greg k-h -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012/06/22 12:03 (GMT+0100) Cristian Morales Vega composed:
the meaning of priorities is the one you would expect. Set them as the common sense tells you to.
Common only to those who think upside down or are a sports nut. For most people higher = more = bigger, and 50 is not higher than 99. Priority doesn't equate to blue, red & yellow like in an Olympic event, dog show or pie eating contest. Miami won the league trophy because it had a bigger number of points. Zero equates to losing out to non-zero. 98 losing to 99 is inane. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 06/22/2012 03:59 PM, Felix Miata wrote:
On 2012/06/22 12:03 (GMT+0100) Cristian Morales Vega composed:
the meaning of priorities is the one you would expect. Set them as the common sense tells you to.
Common only to those who think upside down or are a sports nut. For most people higher = more = bigger, and 50 is not higher than 99. Priority doesn't equate to blue, red & yellow like in an Olympic event, dog show or pie eating contest. Miami won the league trophy because it had a bigger number of points. Zero equates to losing out to non-zero. 98 losing to 99 is inane.
when picking your selection for lunch from a buffet, what is your first priority? actual quality _or_ appearance of the product? of those two, which is first priority, and which is second? which of those would be numbered "1st", and the other "2nd"? if your 99th priority were a LARGE portion, would that be more important than your first and second priorities and so you always would have a very large serving of ugly, low quality food to munch on? so, [with reference to your note above] in pulling software from the 98th priority repo is not "losing to 99" it is winning--and the 50th priority _is_ a higher priority than the 99th... dd -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On 2012/06/23 09:57 (GMT+0200) DenverD composed:
Felix Miata wrote:
On 2012/06/22 12:03 (GMT+0100) Cristian Morales Vega composed:
the meaning of priorities is the one you would expect. Set them as the common sense tells you to.
Common only to those who think upside down or are a sports nut. For most people higher = more = bigger, and 50 is not higher than 99. Priority doesn't equate to blue, red& yellow like in an Olympic event, dog show or pie eating contest. Miami won the league trophy because it had a bigger number of points. Zero equates to losing out to non-zero. 98 losing to 99 is inane.
when picking your selection for lunch from a buffet, what is your first priority? actual quality _or_ appearance of the product?
Neither. I don't eat in restaurants. They don't provide labels telling what besides the obvious is in the food, forcing me to assume it's more manufactured than natural. :-)
of those two, which is first priority, and which is second?
Your restaurant is like the Olympics, pie eating and dog show. First place is a won, a historical concept, past tense, not a goal or ongoing or future activity.
which of those would be numbered "1st", and the other "2nd"?
I don't relate numbers to priorities, only high or low. When numbers must be attached, I think bigger/more/higher, not 0 or 1 = most. Only when something is at the top of a columnar list can I equate 1 to highest, but on a list, the numbers are orthogonal. High/low, position is what's relevant. Top priority is most, no number needed.
if your 99th priority were a LARGE portion, would that be more important than your first and second priorities and so you always would have a very large serving of ugly, low quality food to munch on?
Were I considering it, it would be a go/no go, high/low thing, not requiring of numeric nomenclature.
so, [with reference to your note above] in pulling software from the 98th priority repo is not "losing to 99" it is winning--and the 50th priority _is_ a higher priority than the 99th...
Attaching 0 or 1 to maximum is illogical. 0 is none/nothing/void/null, lowest priority. Next higher would be 1, then 2, then 3.... I'd rather have $100 than $1, because $100 is more. Where better to see the logical conflict than Bugzilla. Near the bottom are two importance lists side-by-side, priority, and severity. The left one puts lowest number but highest priority at the top of the list, while the right one puts most severe at the top. The gist is that common sense WRT priority labeling isn't clear cut sense like Vega, and the zypper designers, apparently think or thought. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
<snip>
so, [with reference to your note above] in pulling software from the 98th priority repo is not "losing to 99" it is winning--and the 50th priority _is_ a higher priority than the 99th...
Attaching 0 or 1 to maximum is illogical. 0 is none/nothing/void/null, lowest priority. Next higher would be 1, then 2, then 3.... I'd rather have $100 than $1, because $100 is more.
Where better to see the logical conflict than Bugzilla. Near the bottom are two importance lists side-by-side, priority, and severity. The left one puts lowest number but highest priority at the top of the list, while the right one puts most severe at the top.
The gist is that common sense WRT priority labeling isn't clear cut sense like Vega, and the zypper designers, apparently think or thought.
I do not intend to sound rude in the following... I know I am quite new here...: Is it important for the user if it is 99, 1, 0 or whatever? I don´t think so as long as it is documented right next to the number (like: mouse over number, info pops up). The world is full of examples where high numbers stand for low or high numbers for high. However, this is not the discussion I intended starting this thread. I would prefer comments on the lack of documentation I pointed out. Especially because I want to help with the documentation voluntarily! Or are there already too many people doing this? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
On Friday 22 Jun 2012 06:41:16 Greg KH wrote:
I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start.
Why is this a Tumbleweed repo priority issue? It's probably just a general "the kde repo is borked" issue which I've been fighting for the past few weeks
FWIW I have just tested the latest packages in KDE:Release:48, they are unborked now. "ksmserver wont start" is a classic symptom of mismatched KDE/Qt libraries and hence messed up repo priorities. Will -- Will Stephenson, openSUSE Board, Booster, KDE Developer SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5 90409 Nürnberg Germany -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
* Will Stephenson
On Friday 22 Jun 2012 06:41:16 Greg KH wrote:
I ask because I believe that my KDE "ksmserver wont start" error of this morning might be related to this. It appeared after zypper dup this morning (64 bit Intel Core2Quad) and won´t let KDE start.
Why is this a Tumbleweed repo priority issue? It's probably just a general "the kde repo is borked" issue which I've been fighting for the past few weeks
FWIW I have just tested the latest packages in KDE:Release:48, they are unborked now.
"ksmserver wont start" is a classic symptom of mismatched KDE/Qt libraries and hence messed up repo priorities.
That "problem" was solved for me (tumbleweed) yesterday. I briefly used icewm. Also python-kdebase4 has updated w/o problem. tks, -- (paka)Patrick Shanahan Plainfield, Indiana, USA HOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 http://en.opensuse.org openSUSE Community Member Registered Linux User #207535 @ http://linuxcounter.net -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
"ksmserver wont start" is a classic symptom of mismatched KDE/Qt libraries and hence messed up repo priorities.
That "problem" was solved for me (tumbleweed) yesterday. I briefly used icewm. Also python-kdebase4 has updated w/o problem.
confirmed! thanks for the info and thanks to GregKH -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (7)
-
Cristian Morales Vega -
DenverD -
Felix Miata -
Greg KH -
Patrick Shanahan -
Thomas Langkamp -
Will Stephenson