Bug 385972

Summary:	make zypper dup error out if more than one repository exists
Product:	[openSUSE] openSUSE 11.0	Reporter:	Dirk Mueller <dmueller>
Component:	libzypp	Assignee:	E-mail List <zypp-maintainers>
Status:	RESOLVED INVALID	QA Contact:	Duncan Mac-Vicar <dmacvicar>
Severity:	Enhancement
Priority:	P2 - High	CC:	coolo, locilka, lslezak, markus.kossmann, mls
Version:	Beta 1
Target Milestone:	---
Hardware:	Other
OS:	Other
Whiteboard:
Found By:	Development	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Dirk Mueller 2008-05-02 11:53:27 UTC

I've just learned over lunch that calling "zypper dup" is wrong if you have both buildservice repositories and a distribution repository enabled. 

apparently one has to call it with -r <name>, where <name> points to the distribution one wants to upgrade to, and the other repositories (e.g. buildservice addons) must not be dup'ed, but only updated via update -t package. I've verified that this indeed fixes the "reinstalling/downgrading package" issues everyone seems to be complaining about. 

It would be nice if zypp/zypper could detect this situation and advise the user, or alternatively do the right thing automatically. 

I'm not sure if channels of distributions (e.g. the factory channel, or a future openSUSE 11.0 channel) can be detected in some way.. if it does, then it could automatically add the -r argument if there is only one distribution channel enabled, and altneratively error out if more than one distribution channel is in the sources list and no -r argument was given.

Comment 1 Stephan Kulow 2008-05-11 08:20:39 UTC

*** Bug 388956 has been marked as a duplicate of this bug. ***

Comment 2 Jan Kupec 2008-05-12 12:04:21 UTC

(In reply to comment #0 from Dirk Mueller)
> I've just learned over lunch that calling "zypper dup" is wrong if you have
> both buildservice repositories and a distribution repository enabled. 
> 
> apparently one has to call it with -r <name>, where <name> points to the
> distribution one wants to upgrade to, and the other repositories (e.g.
> buildservice addons) must not be dup'ed, but only updated via update -t
> package. I've verified that this indeed fixes the "reinstalling/downgrading
> package" issues everyone seems to be complaining about.

Hm. If that is so, this feature is really important :O) Just a side question: how does installation handle this (if at all)?

> It would be nice if zypp/zypper could detect this situation and advise the
> user, or alternatively do the right thing automatically. 
> 
> I'm not sure if channels of distributions (e.g. the factory channel, or a
> future openSUSE 11.0 channel) can be detected in some way.. if it does, then it

Currently they can't, we need to add means of such identification (as well as identification of update repos).

> could automatically add the -r argument if there is only one distribution
> channel enabled, and altneratively error out if more than one distribution
> channel is in the sources list and no -r argument was given.

yup, sounds good

Comment 3 Lukas Ocilka 2008-05-12 12:17:43 UTC

Installation/Upgrade has the installation repository registered as the fist one, then Add-Ons or other repositories can be added or enabled. Upgrade doesn't handle how the packages are selected to be upgraded, it just calls solver.

OK, some packages are dropped by installation by default :) See bug #300540.

Comment 4 Stephan Kulow 2008-05-12 12:25:06 UTC

the main difference: it's pretty unusual to have 13 repos during distribution update with very comparable versions. While it's not to for zypper dup.

BTW: another difference: installations sets YAST_IS_RUNNING=instsys, which some packages cause not to produce errors on updates. This might be good for dup, but bad for update

Comment 5 Duncan Mac-Vicar 2008-12-10 14:31:49 UTC

Moved to feature 305553

Comment 6 Michael Schröder 2008-12-10 14:37:22 UTC

This bug is completely invalid. It is a valid use case to have multiple repositories enabled when calling zypper dup.

Comment 7 Duncan Mac-Vicar 2008-12-10 15:55:34 UTC

Damn, I did a feature out of it :-(

Comment 8 Michael Schröder 2008-12-10 17:26:26 UTC

You shouldn't mix repositories, though. Could your CPEIDs be used to generate a warning in those cases?

Comment 9 Duncan Mac-Vicar 2008-12-10 17:33:57 UTC

Yes, but there are no repositories using the cpeids yet. But will add that to the feature.