Mailinglist Archive: opensuse-features (365 mails)

< Previous Next >
[openFATE 305553] zypper: dist upgrade could error out if more than one repository with a base product exists
  • From: fate_noreply@xxxxxxx
  • Date: Tue, 2 Mar 2010 13:44:28 +0100 (CET)
  • Message-id: <feature-305553-38@xxxxxxxxxxxxxx>
Feature changed by: Andreas Jaeger (a_jaeger)
Feature #305553, revision 38
Title: zypper: dist upgrade could error out if more than one repository
with a base product exists

openSUSE-11.2: Candidate
Priority
Requester: Important
Projectmanager: Important

- openSUSE-11.3: New
+ openSUSE-11.3: Evaluation
Priority
Requester: Important

Requested by: Dirk Mueller (dirkmueller)

Description:
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.

Relations:
- make zypper dup error out if more than one repository exists
(novell/bugzilla/id: 385972)
https://bugzilla.novell.com/show_bug.cgi?id=385972

Discussion:
#1: Stephan Kulow (coolo) (2008-05-11 02:20:39)
* ** Bug 388956 has been marked as a duplicate of this bug. ***


#2: Duncan Mac-Vicar (dmacvicar) (2008-12-10 15:31:24)
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

#3: Lukas Ocilka (locilka) (2008-05-12 06:17:43)
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.

#4: Stephan Kulow (coolo) (2008-05-12 06:25:06)
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

#5: Duncan Mac-Vicar (dmacvicar) (2008-12-10 16:56:35)
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.

#7: Jiri Srain (jsrain) (2008-12-11 07:58:04) (reply to #5)
I don't think it is invalid; I happened to downgrade several packages
from OSS repo via zypper dup :-(

#8: Duncan Mac-Vicar (dmacvicar) (2008-12-11 10:10:32) (reply to #7)
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.

#9: Jiri Srain (jsrain) (2008-12-11 10:53:42) (reply to #8)
Sorry for not being precise in my comment: of course user must be able
to override this error/warning/whatever.

#6: Duncan Mac-Vicar (dmacvicar) (2008-12-10 18:34:19)
Idea from mls: Use the CPE ids introduced in 11.1 to issue a warning if
repositories are mixed.

#10: Ján Kupec (jkupec) (2009-06-24 09:33:26)
Michael, is this still relevant? Is this related to the planned --from
option?

#11: Michael Schröder (mlschroe) (2009-06-24 11:33:46) (reply to #10)
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.

#12: Ján Kupec (jkupec) (2009-07-07 16:26:43) (reply to #11)
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?

#13: Michael Schröder (mlschroe) (2009-07-07 16:34:14) (reply to #12)
ma, is there a libzypp interface?

#14: Michael Andres (mlandres) (2009-07-13 14:16:11) (reply to #13)
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 bnc #459527).

#15: Ján Kupec (jkupec) (2009-07-14 18:17:17) (reply to #14)
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?)


#16: Ján Kupec (jkupec) (2009-07-27 17:30:09) (reply to #14)
Rudi, please look at c#14 and 15

#17: Ján Kupec (jkupec) (2009-07-29 19:04:40)
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?

#18: Ruediger Oertel (oertel) (2009-07-30 17:20:05)
adding more data (like the CPE-ids) is not a big issue. the problem for
me is rather how to obtain a CPE-id

#19: Marcus Meissner (msmeissn) (2009-08-04 17:55:08)
CPE ids can be defined by the vendor as I udnerstand ;)
I mailed Jan and Rudi.
my suggestions would be: cpe:/o:opensuse:opensuse:11.1
cpe:/o:novell:suse_linux_enterprise:11:ga:server cpe:/o:novell:
suse_linux_enterprise:10:sp2:desktop

#20: Ralph Ulrich (ulenrich) (2009-08-05 13:25:05)
(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?

#21: Ján Kupec (jkupec) (2009-08-05 15:02:36) (reply to #20)
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@xxxxxxxxxxxx mailing list. But
you might find the answer also here
http://en.opensuse.org/Product_Management

#22: Ján Kupec (jkupec) (2009-08-19 17:25:34)
We still need to do the TODOs and resolve the issues from c#17 here. If
you have an idea, please speak up.

#23: Klaus Kämpf (kwk) (2009-08-25 09:36:05)
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.


#24: Ján Kupec (jkupec) (2009-11-18 15:59:55) (reply to #23)
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'.

#26: Ján Kupec (jkupec) (2009-11-20 15:29:56)
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.

#27: Jiri Srain (jsrain) (2009-11-25 13:55:01) (reply to #26)
This is all we could do for SP1. Keeping open for further enhancements
for SP2 and/or 11.3.



--
openSUSE Feature:
https://features.opensuse.org/305553

< Previous Next >
This Thread