Hi

Given: SLES11 SP1 ( no patch ) , 32bit Task:, i try to install after an autoyast installation additional software by hand with zipper but getting right away resolve errors.

Example:

Trying to install nmap where libdnet1 & liblua5_1 provides what nmap requires. ( tests with --force-resolution show the same result )

~# /usr/bin/zypper --verbose -v --no-gpg-checks --non-interactive in --auto-agree-with-licenses nmap Verbosity: 2 Entering non-interactive mode. Entering 'no-gpg-checks' mode. Non-option program arguments: 'nmap' Initializing Target Checking whether to refresh metadata for SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152 Checking whether to refresh metadata for SDK Loading repository data... Reading installed packages... Force resolution: Yes Resolving package dependencies... Force resolution: Yes

Problem: nmap-4.75-1.26.i586 requires libdnet.so.1, but this requirement cannot be provided uninstallable providers: libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] Solution 1: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 2: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 3: do not ask to install a solvable providing nmap Solution 4: break nmap by ignoring some of its dependencies

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

Now i try to install liblua5_1 and libdnet1 but the --force option MUST be given

Example: /usr/bin/zypper -v -v --no-gpg-checks --non-interactive in --auto-agree-with-licenses --force liblua5_1 Verbosity: 2 Entering non-interactive mode. Entering 'no-gpg-checks' mode. Non-option program arguments: 'liblua5_1' Initializing Target Checking whether to refresh metadata for SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152 Checking whether to refresh metadata for SDK Loading repository data... Reading installed packages... Force resolution: No Resolving package dependencies... Force resolution: No

The following NEW package is going to be installed: liblua5_1 5.1.4-1.15 i586 SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152 SUSE LINUX Products GmbH, Nuernberg, Germany

1 new package to install. Overall download size: 83.0 KiB. After the operation, additional 187.0 KiB will be used. Continue? [y/n/?] (y): y committing Retrieving package liblua5_1-5.1.4-1.15.i586 (1/1), 83.0 KiB (187.0 KiB unpacked) Retrieving: http://10.11.8.3/export/suse/sles11sp1/x86/media.1/media [done] Retrieving: http://10.11.8.3/export/suse/sles11sp1/x86/suse/i586/liblua5_1-5.1.4-1.15.i5... [done] Installing: liblua5_1-5.1.4-1.15 [done] committingCommitResult 1 (errors 0, remaining 0, srcremaining 0, updateMessages 0)

Afterwards nmap can be installed.

But: If i remove the software and its dependencies via rpm -e - in this case nmap , libdnet1 & liblua5_1 i can install nmap right right away wiyhout any errors.

Is this a know bug or do i something wrong ?

Tia Hajo

on Friday 15 July 2011 Hans-Joachim Ehlers wrote:

Does these looks have any purpose except to drive me crazy ?

no, that was the only purpose ;)

No, seriously, back then, when I wrote that code for <remove-packages>, the taboo for packages was the only reliable way to tell the resolver "believe me, I don't want that package". The resolver always wanted to reselect the package unless it was on taboo. In the meantime the zypp resolver is a lot smarter and I should check that code again to replace it with something better because I think taboo is no longer needed unless you want to "remove-package" a package that is required by another one - then only taboo helps. I'll put that on my todo

. Is there a bug in autoyast which does not removes these locks ?

you can remove the /etc/zypp/locks file in an init-script or so. Then all locks should be gone.

On Mon, Jul 18, 2011 at 10:34, Uwe Gansert ug@suse.de wrote:

on Friday 15 July 2011 Hans-Joachim Ehlers wrote:

...

Does these looks have any purpose except to drive me crazy ?

no, that was the only purpose ;)

No, seriously, back then, when I wrote that code for <remove-packages>, the taboo for packages was the only reliable way to tell the resolver "believe me, I don't want that package". The resolver always wanted to reselect the package unless it was on taboo. In the meantime the zypp resolver is a lot smarter and I should check that code again to replace it with something better because I think taboo is no longer needed unless you want to "remove-package" a package that is required by another one - then only taboo helps. I'll put that on my todo

In some cases, I find the locks quite helpful. Maybe just rename "remove-package" to "taboo-package" (or "(b)lock-package" or something like that) and write a new and shiny "remove-package"? I'd guess the number of people using (the current) remove-package for its locks is quite small, so the backward compatibilty issue would be quite small. Please, anybody using it that way, raise your voice now. (;

On Mon, Jul 18, 2011 at 10:54, Hans-Joachim Ehlers HansJoachim.Ehlers@eumetsat.int wrote:

...

you can remove the /etc/zypp/locks file in an init-script or so. Then all locks should be gone.

I have already extended our current init script to remove the looks via an /usr/bin/zypper --non-interactive rl *

The latter is the documented way to go, but if you use it on embedded hardware, it really makes a difference in terms of speed. While "rm /etc/zypp/locks" only takes a second to remove all (~500) locks, "zypper rl" takes about 25 minutes.

tty,     686f6c6d

Sorry for re-sending, for some reason my reply was rejected.

Am 15.07.2011 17:22 schrieb "Hans-Joachim Ehlers" HansJoachim.Ehlers@eumetsat.int:

Problem: nmap-4.75-1.26.i586 requires libdnet.so.1, but this requirement cannot be provided uninstallable providers: libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] Solution 1: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 2: Following actions will be done: do not forbid installation of libdnet1-1.11-87.17.i586[http-10.11.8.3-bf69b41f] do not forbid installation of liblua5_1-5.1.4-1.15.i586[SUSE-Linux-Enterprise-Server-11-SP1 11.1.1-1.152] Solution 3: do not ask to install a solvable providing nmap Solution 4: break nmap by ignoring some of its dependencies

Now i try to install liblua5_1 and libdnet1 but the --force option MUST be given

But: If i remove the software and its dependencies via rpm -e - in this case nmap , libdnet1 & liblua5_1 i can install nmap right right away wiyhout any errors.

Is this a know bug or do i something wrong ?

Do you have these packages in <remove-packages>? If so, this is the same behavior we see on openSUSE, and I guess it is expected, even though it is a bit annoying.

(Background: We extensively use remove-packages to "block" more than 100 packages from being auto-added during installation, because we don't need them ("default" pattern iirc, we don't use "minimal" for some reason I don't remember right now). During later steps of the machine lifetime, we have exactly the same problem because these packages are forbidden.)

Is there a nicer way to block packages during install only? Forbidding them completely seems to be a bit counter-intuitive, assuming this is the same problem.

tty, 686f6c6d