The following package is going to be upgraded:
sysstat
The following package is not supported by its vendor:
sysstat
1 package to upgrade.
Overall download size: 173.0 KiB. After the operation, 638.0 KiB will be freed.
Continue? [y/n/?] (y):
There are no conflicts that I can see, and if i run zypper up (no
specific package spesified) the self built package is upgraded, and if i
run zypper in -f zypper-locks that package is installed with the latest
version…
That packages are built on a SLES11SP1 system and installed on a
SLES11SP1 system. Packages are rebuilt with rpmbuild -bb package.spec.
Not sure if this matters.
Could this be related to how the packages are built? Has anyone else
seen this problem?
On 05/12/2011 10:06, alexanderdav wrote:
[color=blue]
If i run zypper up zypper-locks i get the following message back:[/color]
What happens if you run “zypper in zypper-locks”?
HTH.
Simon
Novell Knowledge Partner (NKP)
Do you work with Novell technologies at a university, college or school?
If so, your campus could benefit from joining the Novell Technology
Transfer Partner (TTP) program. See TTP Organization | Micro Focus for more details.
On Mon, 05 Dec 2011 15:36:02 +0000, alexanderdav wrote:
[color=blue]
It looks like it does not register the update somehow, when running
install or upgrade direct on the package…[/color]
I don’t have a SLES11 server here to test with, but you might check to
see if there’s a ‘–force’ option, or download the RPM and use rpm -i –
force to get it to reinstall the new version.
It seems that zypper thinks the updated version and the installed version
are perhaps the same.
On Mon, 05 Dec 2011 15:36:02 +0000, alexanderdav wrote:
[color=green]
It looks like it does not register the update somehow, when running
install or upgrade direct on the package…[/color]
I don’t have a SLES11 server here to test with, but you might check
to see if there’s a ‘–force’ option, or download the RPM and use rpm
-i – force to get it to reinstall the new version.
It seems that zypper thinks the updated version and the installed
version are perhaps the same.
Jim
[/color]
Hi
Yes, --force or -f is an option You can also include the rpm
version (good for rolling back).
@OP, if it’s self built, are you updating the release or version number
of the newer rpm, if not this will mean -f needs to be used.
Using rpm or force options is not a good idea. This should work without
needing to apply any extra options. all this is also supposed to be
automated, no interaction from then user when upgrading these
packages…
I have changed both the release and version number. The package is
listed as a upgrade when using zypper lu, but zypper up packagename does
not work…
The only thing this package does is install a new file, but I see the
same for other self built packages that are more advanced…
The reason for that is so called “vendor locks”, which is enabled by
default. This means that zypper is safe by default and does not switch
packages from one Vendor (Vendor:) tag to another Vendor Tag, unless
forced.
It is actually imho a bug that “zypper lu” lists it as update, when the
update can not actually be installed.
Once you’re on your “self-build” version, it will also not switch back
to the Novell/SUSE provided version unless you force it to (for example
via zypper patch or zypper install).
To switch to your version, do something like:
zypper in zypper-locks-1-4.noarch
which should produce output similar to
[color=blue]
The following package is going to be upgraded:
zypper locks
The following package is going to change vendor:
zypper locks SUSE LINUX Products GmbH, Nuernberg, Germany →
This was not a vendor change problem. The problem is that the package
version is 1-4, not for example 1.4.0. When changing the package version
to 1.4 and supplying a update with version 1.4.1 zypper up package-name
works.
I believe this is a bug in zypper, since zypper acknowledges that there
is a available updates, but refuses to update the package.
You can also include the rpm