Jan Engelhardt wrote:
It's time to cut the crap.
Yes, it is.
Three packages ... pam... How many packages and libs depend on PAM and will fail to load because the sym isn't there:
the pam one is due to pam_unix2.so
afs5log chage chfn chsh cimmof cimmofl cimprovider cimsub crontab kdm libCIMQueryCapabilitiesProvider.so libCIMQueryCapabilitiesProvider.so.1 libCIMxmlIndicationHandler.so libCIMxmlIndicationHandler.so.1 libCertificateProvider.so libCertificateProvider.so.1 libConfigSettingProvider.so libConfigSettingProvider.so.1 libDefaultProviderManager.so libDefaultProviderManager.so.1 libNamespaceProvider.so libNamespaceProvider.so.1 libProviderRegistrationProvider.so libProviderRegistrationProvider.so.1 libUserAuthProvider.so libUserAuthProvider.so.1 libpam.so libpam.so.0 libpam.so.0.83.1 libpam_misc.so libpam_misc.so.0 libpam_misc.so.0.82.0 libpamc.so libpamc.so.0 libpamc.so.0.82.1 libsnmpIndicationHandler.so libsnmpIndicationHandler.so.1 libuniconf.so libuniconf.so.4.4 libwvstreams.so libwvstreams.so.4.4 libwvutils.so libwvutils.so.4.4 lxdm osinfo passwd pkexec ssh-keyconverter su uni vtysh wbemexec wvdial wvdialconf xdm (55) How many of those are libs? 33... if 1 lib's fail prevents loading of 22 progs and 33 libs, how many more will the rest block? libpam by itself is bad enough -- that affects a much larger number of programs ssh --- However, note, I DID say this happened a few weeks ago when I was still mostly in 12.1 w/a few 12.2 packages to support the virt-machines (kvm?) that was used in every security util before 12.3. 12.3 replaced it with pam_unix... I went through the rpmsaves/rpmnews to fix all of them. with pam_unix2 linked into every security relevant prog, you are pretty well screwed. I count 76 progs in /etc/pam.d... without those progs you are VERY screwed because you are locked out of the system. So um... tell me about this crap you are cutting? If you can't run any prog to do with UID/GID, accounts, authorization or session validation, What can you run? You think I was exaggerating? It was seriously screwed.
$ rpm -e glibc --test 2>&1 | grep OW_ libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) whois-5.0.11-12.1.1.x86_64 libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) pam-modules-12.1-16.1.1.x86_64 libcrypt.so.1(OW_CRYPT_1.0)(64bit) is needed by (installed) yast2-core-2.23.4-2.1.1.x86_64
But you have to put int a special symbol in the heart of your security and sysadmin (yast) to make it incompat with a standard glibc. PERFECTLY SUSE'S right -- but it is a HUGE Gotcha when one is told glibc is upward compat -- and you hope to try loading a glibc that will be 'compat for all'... The OW_CRYPT stuff really can't be in its own lib?
You can blame perl for that, because its default search path contains the exact version only (e.g. "5.16.2" in case of openSUSE_12.3) rather than a generic "5.16".
The **default** build of perl includes all the dirs of the previous release. Suse strips those out. **** So no -- that's SQUARELY a suse thing**** binding libs of perl/python and ruby in w/your system's text editor--- all suse. I even did the legwork for you you and posted the patch in the bug report -- but it's short enough to include here... cleaned up a few bad dependencies while I was at it... diff vim.spec vim.spec.dyn 42d41 < BuildRequires: systemd 57,58c56 < # Explicitly require versioned perl for libperl.so < %define perl_requires perl = %(rpm -q --qf '%{VERSION}' perl) ---
%define perl_requires perl 318,320c316,318 < --enable-perlinterp \ < --enable-pythoninterp \ < --enable-rubyinterp \
--enable-perlinterp=dynamic \ --enable-pythoninterp=dynamic \ --enable-rubyinterp=dynamic \
-------------- gvim didn't not fail due to a directories problem. It specifically looked for an exact version at install and at RUN time.... it was broken by design (it was designed to break if the user tampered with their system perl). You even have a dep on systemd?!?!?? WTF? gvim doesn't require systemd anymore than it required the sysVinit scripts -- but someone was very determined to make systemd required... just try to do an install w/it banned, and watch the 100's of conflicts that run fine w/o it installed! But lets pretend for a moment that perl's default DIDN'T include the previous release's dirs (but it does)... Suse still knows well how to use symlinks: /usr/lib/perl5> ll total 8 lrwxrwxrwx 1 6 Mar 14 11:03 5.16.0 -> 5.16.2/ lrwxrwxrwx 1 6 Apr 2 22:25 5.16.1 -> 5.16.2/ drwxr-xr-x 61 4096 Mar 26 17:21 5.16.2/ drwxr-xr-x 4 76 Apr 2 22:25 site_perl/ drwxr-xr-x 6 117 Apr 2 22:25 vendor_perl/ Have we cut the crap yet? Would you like cheese on that? I'm citing facts here -- I don't care how these things got this way -- but I know they don't have be deliberately broken. and Christian said to 'do' something? I'm submitting bug reports and patches. I'm telling you how it can be done to get what you want and preserve compat... all I get is a HUGE amount of grief. ;^/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org