Bug 967007

Summary:	systemd updates to 210-40 fail due to weird dependency
Product:	[openSUSE] openSUSE 13.1	Reporter:	Patrick Schaaf <patrick.schaaf>
Component:	Basesystem	Assignee:	E-mail List <bnc-team-screening>
Status:	RESOLVED INVALID	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	openSUSE 13.1
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description Patrick Schaaf 2016-02-17 07:54:22 UTC

Two of my systems refuse the update to systemd-210-40 and friends. The two affected systems are a host, and a VM on it, installed as a minimal base system with no X. The update worked on several desktop and laptop systems, using exactly the same repository as source.

Here is what is shown when trying the update by hand:

awe:~ # zypper up systemd
Loading repository data...
Reading installed packages...
Resolving package dependencies...

Problem: nothing provides this-is-only-for-build-envs needed by systemd-mini-210-40.1.x86_64
 Solution 1: Following actions will be done:
  do not forbid installation of systemd-210-40.1.x86_64[repo-update]
  do not keep systemd-208-23.3.x86_64 installed
 Solution 2: do not ask to install a solvable providing systemd.x86_64 = 210-40.1
 Solution 3: break systemd-mini-210-40.1.x86_64 by ignoring some of its dependencies

Choose from above solutions by number or cancel [1/2/3/c] (c): c

Comment 1 Stephan Kulow 2016-02-17 08:18:32 UTC

"do not forbid installation of systemd-210-40.1.x86_64" sounds like you have a lock. Check /etc/zypp/locks

Comment 2 Patrick Schaaf 2016-02-17 08:24:59 UTC

(In reply to Stephan Kulow from comment #1)
> "do not forbid installation of systemd-210-40.1.x86_64" sounds like you have
> a lock. Check /etc/zypp/locks

Blush.... You are right. And I had these locks for the last 12 months there. Don't remember at all _why_...

The update worked after removing the locks.

Sorry for the noise!