zypper SMT repos / external repos. Newer package versions

SUSE Linux Enterprise Server SLES Configure-Administer
1

Hi there,

I have a questions regarding to zypper configured with the offizial SLES repos from a SMT Server and one external repo from
build service. A colleague who has left the company installed the system.

On the external repos from “Alexander Evseev” are newer Versions of installed software (corosync) that was first installed from the HA repos.
Zypper know from witch repo the packages where first installed.

Information for package corosync:

Repository: SLE-HA12-SP1-Updates

Q: Why zypper do not update the package to the newer Version from the external repo
Only why the package was installed from the SLES repos first ? Or the SLES repos are preferred
To install the newer Versions from Build Service I need to reinstall all Package or can I force zypper to install the updates

*We only need unbound from the external repo from build service

I will understand this because of I will avoid to mix up HA Product(yes we have a license) repo packages and external repos.

SLES 12 (SP1) with HA

***04:/etc/zypp/repos.d # rpm -qa |grep coro
corosync-2.3.5-3.17.1.x86_64

***04:/etc/zypp/repos.d # zypper ref

Repository ‘SLE-HA12-SP1-Pool’ is up to date.
Repository ‘SLE-HA12-SP1-Updates’ is up to date.
Repository ‘SLES12-SP1-Pool’ is up to date.
Repository ‘SLES12-SP1-Updates’ is up to date.
All repositories have been refreshed.

***04:/etc/zypp/repos.d # zypper pa SLE-HA12-SP1-Pool | grep coro
v | SLE-HA12-SP1-Pool | corosync | 2.3.5-2.2 | x86_64
v | SLE-HA12-SP1-Pool | libcorosync4 | 2.3.5-2.2 | x86_64

***04:/etc/zypp/repos.d # zypper pa SLE-HA12-SP1-Updates | grep coro
i | SLE-HA12-SP1-Updates | corosync | 2.3.5-3.17.1 | x86_64
i | SLE-HA12-SP1-Updates | libcorosync4 | 2.3.5-3.17.1 | x86_64

***04:/etc/zypp/repos.d # zypper pa AlexEvseev | grep coro
v | AlexEvseev | corosync | 2.4.2-1.5 | x86_64

***04:/etc/zypp/repos.d # zypper up

The following 65 package updates will NOT be installed:
binutils btrfsprogs conntrack-tools corosync cpp curl dmidecode ethtool kmod kmod-compat libbtrfs0 libcorosync4 libcurl4 libfreetype6
libgcrypt20 libgmime-2_6-0 libharfbuzz-icu0 libharfbuzz0 libinput10 libkmod2 libldb1 libmm-glib0 libmtp9 libnetfilter_conntrack3
libnfnetlink0 libnl3-200 libnuma1 libopus0 libruby2_1-2_1 libsnappy1 libsnmp30 libsolv-tools libtalloc2 libtdb1 libtevent0 libusb-1_0-0
libvdpau1 libvte2_90-9 libwacom-data libwacom2 libxml2-2 libxml2-tools libyaml-0-2 libzypp net-snmp numactl ocfs2-tools pacemaker
perl-SNMP python-cffi python-cryptography python-idna python-pyOpenSSL python-pycparser python-six python-solv ruby ruby2.1 ruby2.1-stdlib
snmp-mibs syslinux tdb-tools vte-lang xfsprogs zypper

THANKS

*T

2

I believe this is because you are changing vendors of packages, and
normally that is not the best idea unless you mean to, for example that
has happened when changing service packs (more than regular
patching/updates) and usually you get a big warning about the change, even
if it is from ‘SUSE’ to ‘SUSE Linux’ or vice versa. As it is, though, the
system is protecting you from voiding support, accidentally
mixing/matching packages that may not work together, etc.

–
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.

If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.