Home_greyopenFATE - openSUSE feature tracking > #305553
Dashboard | Search | Sign up | Login

Please login or register to be able to edit or vote this feature.

zypper: dist upgrade could error out if more than one repository with a base product exists

Feature state

Rejected Information


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.



icons/user_comment.png S. K. wrote: (10 years ago)

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

icons/user_comment.png D. M. wrote: (9 years ago)

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

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

yup, sounds good

icons/user_comment.png L. O. wrote: (10 years ago)

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.

icons/user_comment.png S. K. wrote: (10 years ago)

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

icons/user_comment.png D. M. wrote: (9 years ago)

Note, I moved the bugzilla entry to fate, but mls claims the bug is invalid, as it is a perfect use case to do dist upgrade with various repositories. So this feature has to be evaluated with care and gathering opinions from various sources. It may be invalid.

icons/user_comment.png J. S. wrote: (9 years ago)

I don't think it is invalid; I happened to downgrade several packages from OSS repo via zypper dup :-(

icons/user_comment.png D. M. wrote: (9 years ago)

The solution of stop-with-error if there is more than one repository is invalid because prevent the valid usecase of dist-upgrading with more than one repo enabled (as mls pointed out).

What is valid about the feature, is that multiple repo upgrade can be dangerous, and we may warn the user if there are repos for different products there.

icons/user_comment.png J. S. wrote: (9 years ago)

Sorry for not being precise in my comment: of course user must be able to override this error/warning/whatever.

icons/user_comment.png D. M. wrote: (9 years ago)

Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if repositories are mixed.

icons/user_comment.png J. K. wrote: (8 years ago)

Michael, is this still relevant? Is this related to the planned --from option?

icons/user_comment.png M. S. wrote: (8 years ago)

This has nothing to do with --from, it's about doint 'zypper dup' to update the system to the next release while still having old repositories enabled.

icons/user_comment.png J. K. wrote: (8 years ago)

So multiple repositories are not a problem in general, but
multiple repos for different products are! OK, so now back to the solution: can you tell me or point me to some info abou these CPEs Duncan mentions in c#6? I guess they are part of the product solvable and are available as solv attribute?

If so, all that's needed is to check whether there are multiple repos with a different product and write a warning if that's the case, right?

icons/user_comment.png M. S. wrote: (8 years ago)

ma, is there a libzypp interface?

icons/user_comment.png M. A. wrote: (8 years ago)

Yes. Since you can ask for a products CPEid, or for the CPEids related to a repository (supported or updated products). But I don't know if those CPEids are meanwhile included in the metadata (see Bug #459527).

icons/user_comment.png J. K. wrote: (8 years ago)

OK, so this should not be too much work. So to sum it up:

  • zypper: show a warning in 'dup' if there are multiple
    base repos with different CPEids enabled.
  • metadata: check/include the CPEid in product metadata (who should do this?)
icons/user_comment.png J. K. wrote: (8 years ago)

Rudi, please look at c#14 and 15

icons/user_comment.png J. K. wrote: (8 years ago)

Current status:

  • TODO: put CPE IDs to content/prodcuts.xml metadata (still nobody assigned to do this!)
  • TODO: satsolver will need to parse the above (or is this ready already?)
  • PROBLEM: we need to figure out which repos don't go together for dup. I proposed to compare CPEs of 'base' or 'platform' repos, but we have no 'isBase' flag in product or repo metadata. Simply checking for different CPEs is not enough (think of one base product and one addon - two different CPEs, but 'dup' is OK with them).
  • PROBLEM: even if we'll have the 'isBase' flag, we'll be stuck in case of two different, but compatible bases, like e.g. SLES and SLED could be used standalone or with SLED as an add-on to SLES in the past. Do we still allow this?

Any ideas?

icons/user_comment.png R. O. wrote: (8 years ago)

adding more data (like the CPE-ids) is not a big issue. the problem for me is rather how to obtain a CPE-id

icons/user_comment.png M. M. wrote: (8 years ago)

CPE ids can be defined by the vendor as I udnerstand ;)

I mailed Jan and Rudi.

my suggestions would be:


icons/user_comment.png R. U. wrote: (8 years ago)

(beginners question) Why products at all. Debian/Ubuntu do have so called
meta-packages , which are normal package that pull in stuff: minimal, standard ...etc

Without products you would loose an additional level of complication?

icons/user_comment.png J. K. wrote: (8 years ago)

Using metapackages for puling stuff does not exlude using of CPE ID. It's just means to uniquely identify a product and can be used by Debian's metapackages as well.

Other than that, your question is not related to this FATE, and is more appropriate for opensuse-softwaremgmt@opensuse.org mailing list. But you might find the answer also here http://en.opensuse.org/Product_Management

icons/user_comment.png J. K. wrote: (8 years ago)

We still need to do the TODOs and resolve the issues from c#17 here. If you have an idea, please speak up.

icons/user_comment.png K. K. wrote: (8 years ago)

I believe the request title is wrong and should be adapted.

Indeed 'distribution upgrade' is special, as it considers one repo to be 'authorative' and thus dictating package versions, which might result in a version downgrade.

'zypper dup' should provide support for this and, in case of multiple 'product' (resp. base) repositories request a decision from the user.

There are two things to be solved from my pov

  • Detection of a 'base' vs. 'addon' repo. Could be done by looking at a 'product' resolvable.
  • Specifying the 'authorative' repo in case of dist upgrade. ie. passing a '--product foo' or '-to repo' to zypper.

icons/user_comment.png J. K. wrote: (8 years ago)

Detection of base vs. addon is what we currently lack.
The authoritative repo can now be selected using --from option. 'zypper dup --from repo-oss'.

icons/user_comment.png J. K. wrote: (8 years ago)

Following Jiri's suggestion, i've done this the simple way for now: if --repo or --from are not used, and multiple repos are enabled, 'zypper dup' will show a warning and a hint that the user should check the repo list for incompatible repos.

icons/user_comment.png J. S. wrote: (8 years ago)

This is all we could do for SP1. Keeping open for further enhancements for SP2 and/or 11.3.

icons/user_comment.png J. K. wrote: (8 years ago)

Marking as done also for 11.2 since the SP1 package will also be released as update for 11.2.

Last change: 4 years ago
Score: 3
  • Negative: 0
  • Neutral: 0
  • Positive: 3
Feature Export
Application-xmlXML   Text-x-logPlaintext   PrinterPrint