Mailinglist Archive: opensuse-factory (600 mails)
| < Previous | Next > |
Re: [opensuse-factory] Anit-Vendor Change Extremism - Call for discussion
- From: Stephan Kulow <coolo@xxxxxxxxxx>
- Date: Thu, 22 Oct 2009 12:27:15 +0200
- Message-id: <200910221227.15953.coolo@xxxxxxxxxx>
Am Dienstag 20 Oktober 2009 schrieb Martin Schlander:
We just had a little discussion here with the zypp guys and the outcome is:
vendor change protection is a good thing, but the current implementation of
the tools just leaves too much room for improvement. But changing the default
will cause more trouble than good - mainly because then the priorities get
a lot more attention from the solver and those are even less tested (or
understood by users).
From what most people in this thread suggest, users should do a "zypper dup"
once they registered all repostories they want to track and following they
should use the UI to see single updates or use zypper up. That the UIs do not
have a way to do that currently is something that is sad, but not a desaster.
Possibly we can add a hook for 11.2 to allow switching to the versions of a
specific repository in the UI, at least it sounds possible without too much
risk.
And as said in the bug, I see the "libxine1 case" to be solver easier: if
Packman offers an additional package that requires _their_ libxine1 version,
you can force the solver in always sticking to the packman version, no matter
which repo gets the highest version. The "switch to latest Foobar" use case is
more worrying to me. And there zypper dup is the only choice so far. But it
basically has been that case with 11.1 too, because e.g. KDE did so many
package splits and renames that were never catched with any UI or zypper up.
And now you have a --from option (which is currently broken in RC1) so you
can do zypper dup --from FooBar.
So to summarize: Our tools may behave differently in 11.2 than they did in
11.1, but that doesn't mean we have to throw away the vendor stickyness
feature.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
Personally I think this is a total disaster for openSUSE, and a nightmareHi,
for anyone who tries to promote openSUSE and help newbies.
Is it just me?
We just had a little discussion here with the zypp guys and the outcome is:
vendor change protection is a good thing, but the current implementation of
the tools just leaves too much room for improvement. But changing the default
will cause more trouble than good - mainly because then the priorities get
a lot more attention from the solver and those are even less tested (or
understood by users).
From what most people in this thread suggest, users should do a "zypper dup"
once they registered all repostories they want to track and following they
should use the UI to see single updates or use zypper up. That the UIs do not
have a way to do that currently is something that is sad, but not a desaster.
Possibly we can add a hook for 11.2 to allow switching to the versions of a
specific repository in the UI, at least it sounds possible without too much
risk.
And as said in the bug, I see the "libxine1 case" to be solver easier: if
Packman offers an additional package that requires _their_ libxine1 version,
you can force the solver in always sticking to the packman version, no matter
which repo gets the highest version. The "switch to latest Foobar" use case is
more worrying to me. And there zypper dup is the only choice so far. But it
basically has been that case with 11.1 too, because e.g. KDE did so many
package splits and renames that were never catched with any UI or zypper up.
And now you have a --from option (which is currently broken in RC1) so you
can do zypper dup --from FooBar.
So to summarize: Our tools may behave differently in 11.2 than they did in
11.1, but that doesn't mean we have to throw away the vendor stickyness
feature.
Greetings, Stephan
--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-factory+help@xxxxxxxxxxxx
| < Previous | Next > |