Bug 310455

As a complete guess (without looking at logs) It looks like it is confusing the vendor change with an architecture change. I have had this several times when it wanted to change libtunepimp from suse version to packman version. It would complain that the architecture would be changed from i586 to i586, where the only change was vendor.

Francis, please attach a 'solver testcase'

Created attachment 164063 [details]
Solver Test Case

Sure.

This happens with many other things from Packman. For example, try to install gstreamer010-plugins-good when you already have gstreamer010-plugins-base installed. It will get into an endless loop with a dialog warning you about changing the architecture. 

If this really happens with many packages from other vendors, I would certainly say it was critical, if not a blocker.

possibly it's just a confusing message. We definitely want the user to confirm he wants to exchange SUSE packages with non-SUSE packages. It shouldn't talk about "architecture" though

Hm, the testcase does not reflect the reported error 

But I can reproduce it

Fixed and testcase added to testsuite:
>!> amarok-xine cannot be installed due to missing dependencies
>!> There are no installable providers of amarok == 1.4.7-111.pm.4 for amarok-xine-1.4.7-111.pm.4.i586[1]
>!>    Solution:
>!>       Install amarok although it would change the vendor
>!>       amarok-1.4.7-111.pm.4.i586[1] provides this dependency, but would change the vendor of the installed item
>!>    Solution:
>!>       do not install amarok-xine
>!>       do not install amarok-xine-1.4.7-111.pm.4.i586[1]
>!>    Solution:
>!>       Ignore this requirement just here

I'll test this as soon as I can as well, but IMO it really _shouldn't_ ask you about changing vendor. This is either a real hassle (I've added a repository to get a package but I have to click "accept solution" 3 times), or my girlfriend, my Dad, and my younger brother (new users) won't really have a clue what vendor means, and they'll be confused, and probably ask me for help :-)

YaST/Zypper really needs to make more decisions by itself, and vendor is a pretty good example. Continuous prompting just makes the user think that they've either broken something, or that the solver has failed and it can't do things on its own (users from other distributions very frequently make this complaint). 

This simple case is an example. I have a nice ymp that selects amarok to be upgraded (and hence install packman), but 1-Click install won't work because you have to say that you'd want to change the vendor of amarok (choose option, then click), amarok-xine (again, choose option, and another click), amarok-yauap (for a third time) and then you have to click "finish". 

Fix looks good for 10.3

It does indeed need a more "proposed complete solution" approach than the current "try and fix it yourself" approach. But that is a non-trivial enhancement request for the future. 

For now you should be able to fulfil your usecase by removing the original vendor package first in the YMP.

Created attachment 173603 [details]
latest solver testcase

This still isn't working properly; attaching testcase.

Reopening.

Hm, which error message are you getting ?

As I understand this is now about enhancements to the solver

Created attachment 173628 [details]
zypper install amarok-xine

Hrm, yeah, perhaps.

You are taken on a long trip which eventually refuses to install all the libtunepimp-* stuff. Check attachment.

I'm unsure about how to leave the status of this (enhancement or critical), but I definitely think it shouldn't behave in this way, and that it's a very serious issue. It makes it a complete and utter nightmare for people trying to install things from other repositories.

With the ymps I've had too many complaints to count; everyone thinking that yast has failed to resolve things. Just try using http://opensuse-community.org/codecs-gnome.ymp and see the unresolvable mess that you get into if you just go through with the default settings.

There's nothing extravagant being done there -- just selecting a few additional packages to be installed from another repository. I honestly fear that a lot of users will start recommending smart again, which is a huge pain.

Is there no possibility of just removing all vendor warnings for this release until there's a better selector perhaps in 11.0?

I can't see why it has been brought down to "enhancement", it's pretty much locking out 3rd party packagers out of libzypp because it craps out.
How can this possibly not be at least "critical" ?

I have nothing much to add to what Francis said in comment #16, but I'm really tempted to consider this a blocker. 

Just consider that with this issue, openSUSE is going to ship again, after 3 development periods, with a rough and not fully friendly and easy to use package manager. 

It's becoming annoying and it's hard to explain to users that, after the experience with zmd, we had a temporary fix with 10.2 and we expected a final fix with 10.3, but due to lack of time, we will probably have it for 11. 

Now it's difficult to understand why we haven't a fully working package manager without major issues like this one. It's hard to justify it, independently from the point of view. You had 8 months for 10.3, and at least 6 months considering 10.2 development period too. Fixing the package manager had to be mandatory, which means _all_ efforts should have gone there, if you knew you were strict on time.

With kind regards,
A.

"We definitely want the user to confirm
he wants to exchange SUSE packages with non-SUSE packages"

On a fresh 10.2 install, there are ~100 rpms which updatet by packman, i don't want to kill my mouse!

I wait for the black screen with one little window and the text "Are you realy sure to do this?"

Created attachment 174100 [details]
untested patch to disable vendor change being considered a problem

Added a silly patch that makes all vendors equivalent, which should effectively disable a vendor change being considered as a "problem" and an unresolvable dependency by libzypp.

Patch doesn't do what it's intended to do. I've no idea why but libzypp thinks the architecture is changing when the vendor comparison returns true.

Also just disabling the vendor sticky doesn't solve the problem, although it is arguably the lesser of two evils at this point.

(In reply to comment #21 from Benjamin Weber)
> Patch doesn't do what it's intended to do. I've no idea why but libzypp thinks
> the architecture is changing when the vendor comparison returns true.

This is really, really weird, and definitely smells like a bug somewhere else.
If that's the case, then considering "SUSE" and "openSUSE" as equal vendors doesn't work either (that's 2 lines higher than my patch in that C++ file).

> Also just disabling the vendor sticky doesn't solve the problem, although it is
> arguably the lesser of two evils at this point.

Absolutely, I forgot to add that.

The best solution would be to have an informative message in the actions to be performed (that a vendor change will take place for that package), but not to prompt the user about whether to do the vendor change.

And indeed, in my opinion too, it's better to not have any vendor change handling at all than the current situation. Unless there's time to implement the suggestion above (have an informative message instead of doing it silently) ;)

Sorry guys. You know that registering "Packman" can cause any kind of problems you're willing to solve. But many others don't and they will cause tons of bug reports because they managed to replace half their system with packman packages without even understanding it.

As a matter of fact you just have to read opensuse-factory to figure half the "blocker" reports are due to packman having packages in 10.3 repo that do not fit 10.3. And _that_ exactly is the reason we definitely do want the vendor change to be approved. Package by package. 

The enhancement is basically about grouping these packages and requiring _one_ click for the "I would replace these 100 packages", but we're not there yet.

If there is genuinely a problem with the packages in Packman perhaps we can encourage them instead to fix any of the issues with them instead, and perhaps (if this isn't done already), make sure that they only have packages that _have_ to be there (and hence push the rest -- backports, etc -- out to the build service.

The current method just makes things extremely difficult, if not impossible, for all 3rd-party packagers, since they can by no means really say to the user "add this repo to get the package X". It becomes a much longer process, and a more difficult one for the user. Most of my family members wouldn't be able to complete it. 

Other distributions don't do anything like this and SUSE has never done it in the past; I really don't see why we should deviate from this so directly. Especially since it's going to make the user think one thing, and one thing only -- yast can't do something basic like package management (this is what they always say, and it's sad), and they'll use smart which doesn't give them errors out all the time. 

A hundred people saying on the internet "forget yast" or "yast sucks, use smart" is not exactly helping anything IMO, and is even worse because people don't make the distinction between yast software management and yast, which is itself amazing. 

OK, I just tested registring packman and updating amarok-xine and MPlayer on 10.3 RC1 and I needed 5 clicks. I don't think this is so severe.

coolo you might have lived at the receiving end of packman caused bugreports
for a little too long. In general we wouldn't be where we are at with opensuse
if we wouldn't have that repo. So making this work is crucial.

That the yast ui's cant present the user grouped questions is more then an
enhancement. It seriously hinders (installing from ANY 3rd party repo no matter
how un-intrusive it is) work, especially for newbies. So this is way more then
an enhancement. Its even a regression because we newly introduced those
questions because of a policy change. 

It's worth to note though that only installing packages that replace packages is a problem. Installing from 3rd party repo is not a problem in general.

So my suggestion to packman would be to provide amarok-xine-pm, because then you can register packman and can pick only those packages you want to have from them. Right now it would simply battle with KDE:Backports who first gets the latest version out. But if there is an amarok-xine-pm it's clear the user wants to wait for the version update in packman repo.

And this seems to be very general problem _within the packman project_. Our policy change just made it clearer where the problem is.

I'm aware that some people in the CC feel that every packman package is better than any other package out there and it's very fine to be proud of it (I completely agree with Henne there), but I still feel that it should be left to the user to decide what he wants from whom.

That our solver doesn't make it easy is a clear problem though.

(In reply to comment #27 from Stephan Kulow)
> It's worth to note though that only installing packages that replace packages
> is a problem. Installing from 3rd party repo is not a problem in general.

True.

> So my suggestion to packman would be to provide amarok-xine-pm, because then
> you can register packman and can pick only those packages you want to have from
> them. Right now it would simply battle with KDE:Backports who first gets the
> latest version out. But if there is an amarok-xine-pm it's clear the user wants
> to wait for the version update in packman repo.

Yes. Or rather, the user explicitly wants to have the amarok build with support for MP4 (as MP3 and such is actually handled by Packman's libxine1), MySQL and PostgreSQL (which are the other features not present in the SUSE amarok builds).

That's an option. What we were discussing and considering yesterday was to create an additional subpackage "amarok-with-full-codec-support" that would explicitly Requires: the Packman amarok packages.
That would at least prevent from accidental upgrades to the KDE:Backports amarok packages (and loosing full codec support).
But it won't work around this bug in the solver (it's definitely a bug to me).

> And this seems to be very general problem _within the packman project_. Our
> policy change just made it clearer where the problem is.

How is providing upgrades of packages present in SUSE a "general problem within the packman project" ?

> I'm aware that some people in the CC feel that every packman package is better
> than any other package out there and it's very fine to be proud of it (I
> completely agree with Henne there), but I still feel that it should be left to
> the user to decide what he wants from whom.

Sure. And the question isn't that the Packman packages are better than SUSE packages -- which isn't the case, actually, some are, some aren't ;)
Point is that the Packman packages are either more recent or more feature complete, mostly wrt codec support. Just to clarify, as you seem to imply we're doing some sort of virtual comparison of male organs here.

> That our solver doesn't make it easy is a clear problem though.

Indeed.

But I suppose there aren't any changes that it gets fixed before 10.3 GM, so we'll have to try to find some ugly hack to work around it.

One technical solution is to add Packman as a trusted vendor into the file

"/etc/zypp/trustedVendors"

In principle, single-click install could do that, although a confirmation is clearly needed.

(In reply to comment #21 from Benjamin Weber)
> Patch doesn't do what it's intended to do. I've no idea why but libzypp thinks
> the architecture is changing when the vendor comparison returns true.

My bad, I think I was hitting another bug here. It does seem to disable the vendor change warning in most cases.

Due the new SAT solver we are grouping solutions now. So this issue
should be fixed automatically now ;-)