My fully-patched SLES 11 x86_64 machine had Samba 3.2.7 from the Novell install media. * I added this repository URL to the machine's installation sources in YAST: http://download.opensuse.org/repositories/network:/samba:/STABLE/SLE_11/ * I searched in YAST's "software maintenance" for "samba," then selected the 3.5.1 elements to update. But I noticed that critical parts, e.g., winbind, showed their available and installed version as 3.2.7. In other words, had I proceeded, YAST would have left me with a mix of 3.5.1 and 3.2.7 pieces of Samba, which I assume would be a bad thing. * I uninstalled all 3.2.7 elements, then repeated the above process. YAST's list of Samba elements was then mostly 3.5.1, including winbind. But there were other dependency problems so my guess is I've now got quite a mess to clean up. It seems to me the above should not happen, so I report this is a problem. I experienced a similar problem 1.5 years ago.
This might happen due to a vendor change. You might ask "WTF is a vendor change?". On your system you have Samba packages installed from the plain SLE 11 media. Now you add network:samba:STABLE from the openSUSE Build Service. The Samba packages available there are from a different vendor. This might sound very strange as SUSE Linux Enterprise and openSUSE are products from Novell. But the general approach I consider right. This mechanism protects you from accidentally changing the vendor of a package you might unintentionally get from a repository you added. Theoretical example: You added network:samba:STABLE and this repository also offers a newer bash package. But all you want are the Samba pieces. http://en.opensuse.org/Samba#openSUSE_Build_Service includes an example how to limit the upgrade to one repository while using the zypper command line tool. zypper -r network_samba_STABLE dup You get the "network_samba_STABLE" repository definition ready to use as soon as you install the samba-repo-network_samba_STABLE package available from the network:samba:misc repository of the openSUSE Build Service. Are you still facing the same issue as soon as you use "zypper -r ..." as suggested above?
Created attachment 5609 [details] Results from two zypper commands * two informational commands: zypper se -d -s -i samba zypper se -s -r SLE_11_Samba * repo alias: SLE_11_Samba is the opensuse SLE 11 Samba repo
Thank you, Lars. WTF, indeed! Using zypper to explore the opensuse repo, and the -i option, has helped me understand what's installed on my machine. I also learned in Yast how to select a *version* of a package from among those availabe across repos. I believe this is analogous to your zypper -r suggestion. At the same time, you've released 3.5.2. So I used Yast to carefully update packages, in every case making sure the update came from the opensuse repo. This left me with a few issues left to clean up. If you could advise me about these, I'd appreciate that. It seems that there is no bug in the opensuse packaging, as I'd first suspected. If this conversation would be better done elsewhere, please tell me and I'll go there. In the questions below, I refer to an attached text file showing zypper output from my samba install. Questions: * the first zypper output shows I still have this older version: libtalloc1 | package | 3.2.7-11.9.1 | x86_64 | SLES11-Updates libtalloc1-32bit | package | 3.2.7-11.9.1 | x86_64 | SLES11-Updates because the opensuse repo doesn't provide libtalloc1 (but does provide libtalloc2). Is libtalloc1 obsoleted or unusued in these versions of Samba, and hence removable? * The second zypper output (of the opensuse repo) shows a mysterious pattern in my "status" column: "v" (small extract below). The man page for zypper isn't thorough about the meaning of "v" but I'm wondering if your analysis of vendors is involved, and if this is a problem for me to correct. See how the i586 arch often has the "v" status? I associate u586 with 32 bit code, but (below) see a *third* libwbclient0 claims to be 32 but with x86_64 arch. This is WTF??? to me. ;-) Yast's package versions shows something similar -- I now think perhaps this is just some subtle optimization for a different cpu that perhaps I do not need to worry about. i | libwbclient0 | package | 3.5.2-1.1 | x86_64 | SLE_11 Samba v | libwbclient0 | package | 3.5.2-1.1 | i586 | SLE_11 Samba i | libwbclient0-32bit | package | 3.5.2-1.1 | x86_64 | SLE_11 Samba i | samba | package | 3.5.2-1.1 | x86_64 | SLE_11 Samba v | samba | package | 3.5.2-1.1 | i586 | SLE_11 Samba * Finally, do I need netapi?
a) libtalloc1 got obsoleted. But installed binaries might still required it. A "zypper rm libtalloc1" will display you any dependency _before_ the removal. b) libwbclient0-32bit is the 32bit version of the package installed on a 64bit - in your case a x86_64 - system. These 32-bit packages are required by the PAM stack for example or by 32bit plugins of web browsers. For the v state on a current system the zypper man page states: v - another version installed c) If libnetapi isn't required by any package it's ok if it's not installed. This is true as long as you install software as RPM, via zypper, or YaST. As soon as you try to compile software at your own you might need the libnetapi and libnetapi-devel package. But configure or any other mechanism in use will complain immediately. Anyhow I'm going to close this issue as invalid as all is a feature and not a bug.
Agreed. We will proceed with all that in mind. Thanks for the help.