https://bugzilla.novell.com/show_bug.cgi?id=331540#c2 --- Comment #2 from Maciej Pilichowski 2007-10-06 04:35:16 MST --- (In reply to comment #1 from Stephan Kulow)

The reason is simple: gimp is required for imaging.

No, it is not. libgimpsomething is required for gimp, but imaging without gimp is just fine -- see above example.

if you remove gimp, it will tell you that you break "imaging"

It does not make sense. What does it mean "break"? User simply wants everything from imaging without gimp. I would like to buy all paints in the shop except red.

So you as experienced user know that you don't want gimp. But if someone unexperienced likes to deinstall everything that rhymes on pimp, he better gets told that this will break imaging. That's the reason.

There is a problem with "break" word here again. I am out of ideas how to explain simpler :-) Maybe like this: a) I would like to have gimp, something is required for this (libgimpprint for example), ok b) I would like to not having gimp, now, how anything is required here -- I simply stated I don't want it. Yast should help, not add another obstacle. How not having gimp is a problem for user? He/she does not like it, does not want it, please remove it, and yast shows "problem with imaging". Maybe one more crucial note -- it is not a big deal when you are about to remove one package. But remove ~100 of them and you will be flooded by conflicts at package level (useful) and pattern level (waste of time). Reason: user has to read all of this and it is easy now to make a mistake (I try to upgrade 10.2 on slower computer to 10.3 and exactly this, reporting problems with patterns is a real struggle). Ok, Stephan, if you are not convinced yet, I rephrase it :-D Please add option to control package removal: ( ) report problems at all levels ( ) report problems only at package level It could be even put next to autocheck as checkbox [x] report broken patterns What do you think? I hope this last suggestion is ok. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331540#c4 --- Comment #4 from Maciej Pilichowski 2007-10-11 04:37:45 MST --- Stephan, gimp was just an example. It is not solution to fix gimp -- because other pattern remains so restrictive. So what about my suggestion. Another examples are (they are just examples!) -- kpowersave, kdepim-notes. I see no point in "fixing" each single package<->pattern relation. Ignoring reports from pattern would solve this once for good. What do you think? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331540#c6 --- Comment #6 from Maciej Pilichowski 2007-10-11 05:12:10 MST ---

ignoring "reports from patterns" would make patterns useless.

Not true. Because they are useful when adding packages -- but quite obviously there is no purpose to report user with errors when user would like to install half of that pattern.

he KDE pattern is only fullfilled if everything we think makes up an openSUSE KDE is installed. If you wish to deinstall some of them, you do no longer have openSUSE KDE.

Ok, I would like to have installed partial openSUSE KDE. How can I do this: a) semi-automatically (i.e. not by selecting by hand hundred of packages) b) without tons of "errors" Currently patterns are not design for situation "everything except ..." and such situation is quite natural. In other word -- problem is deeper, in pattern design, not in individual pattern.

So these _are_ pattern bugs and should be reported as such

Yes, but reporting such stuff is just wasting time of people who make those patterns and reporters. Because such problems are artificial -- due to design flaw "problems" arises and now all those should be handled manually. This is wrong. And once again, those are examples -- I cannot test every single package and report to relax requirements. Doing this globally in yast would solve this. And still patterns would be extremely useful. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331540#c8 --- Comment #8 from Maciej Pilichowski 2007-10-11 06:07:55 MST --- Stephan, stop thinking about this pattern thing. You are so addicted to it (nothing personal) that you look at it like an ultimate perfect solution. My point is -- I have task to do. How to do it efficiently? Call it pattern, template, path, whatever, name is not important, important thing is how it works. Task is: please install everything from Z family except A. What would you design? Me: I would design templates (just to avoid naming confusion) -- a template would be equivalent of manual selection of packages. So if user clicks "install" on template all packages defined there are marked as install (AND NOTHING MORE). If user clicks "refresh" -- per analogy. And so on. As you can see, user if free to click "install" on template (all packages are selected as "install") and then "unistall" on package "A". Task done. In user-friendly manner, a lot of time saved, no obstacles. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=331540#c10 --- Comment #10 from Maciej Pilichowski 2007-10-12 06:28:47 MST --- Thank you Klaus, I wanted to say I just posted the wish, but now I see I missed factory ML. I posted it to softwaremanagement -- I hope it is ok too. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.