Re: [opensuse-factory] BUG -- programs requiring specific library versions -- not 'minimum versions'...
Nelson Marques wrote:
Example -- make gvim dependent on 'perl', then it runs no matter what the version.
I think that what you missed was one very important thing:
* libperl.so does not include any interface version number - since it provides embedded perl functionality you need some versioning.
Who is 'you'? Vim doesn't need it. Vim only uses libperl to provide optional perl functionality to be used by the user at run time. Even in perl, if you do a: "use 5.14.0;" That only give you an assurance that you are running, at least, under 5.14.0 OR higher. It's not limited to 5.14.0. Even perl does not restrict programs to a fixed version. But Suse added exact version requirements to vim and and other programs making it impossible to upgrade piecemeal. It's one thing to say you must have *at least* this version, but requiring *exact* versions is Bad software practice. It is as bad or worse than hard-coding absolute pathnames. Many programs under the 12.X series now have exact dependencies on GLIB x.14, x.15, x.16... etc... (12.1/12.2/factory), which means binaries from one version are BOTH forwards and backwards incompatible. That's a violation of basic software design and support that is unthinkable. It would be like all software vendors 'failing' to load if MS updates any library. That is a worse case of DLL hell that what MS had. MS's DLL hell happened because they only allowed 1 version of a shared library **in memory** at the same time. If an old piece of software loaded an old version of some library, then a newer piece of software wouldn't load because it needed a newer version of the library that couldn't be loaded. They fixed this in Vista, about 8-9 years ago. In the suse version of DLL hell, they only allow 1 version of a library to be loaded onto a machine at all (as rpm will uninstall old versions). AND -- software doesn't have requirements for a "MINIMUM" version, but an exact version -- meaning that newer versions of the library can't be used to support old versions. Generally speaking libraries are **usually** backwards compatible and this type of requirement is unnecessary. When there is a large interface change, you end up with a major re-release of the library -- like libreadline5 + libreadline6 -- both of which can be used and required at the same time. This is what I meant earlier by suse creating damage much faster than I can even documented it, let alone fix. That's even assuming I wasn't argued to death about why standard software practices were no longer reasonable or desirable... which isn't the case with many developers who feel bad SW design should be justified rather than fixed. More than one person has said, we don't care what you want -- this what we are doing and this is what is going to be, deal with it. That type of attitude indicates they don't care about users or anyone other than themselves. This is the suse "community"?? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
El 11/12/12 18:43, Linda Walsh escribió:
Even perl does not restrict programs to a fixed version. But Suse added exact version requirements to vim and and other programs making it impossible to upgrade piecemeal. It's one thing to say you must have *at least* this version, but requiring *exact* versions is Bad software practice.
It is doing exactly what we want it to do, that is, what people who have to deal with the distribution maintenance expressed.
It is as bad or worse than hard-coding absolute pathnames.
Many programs under the 12.X series now have exact dependencies on GLIB x.14, x.15, x.16... etc... (12.1/12.2/factory), which means binaries from one version are BOTH forwards and backwards incompatible.
You do not understand what backwards compatibility is. Application X that was linked on openSUSE 12.x with glibc should work unmodified in factory. not the other way around or any different combination. -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Example -- make gvim dependent on 'perl', then it runs no matter what the version.
I think that what you missed was one very important thing:
* libperl.so does not include any interface version number - since it provides embedded perl functionality you need some versioning.
--- Who is 'you'? Vim doesn't need it. Vim only uses libperl to provide optional perl functionality to be used by the user at run time.
Linda, My interpretation was that you wanted to replace a versioned dependency for a non-versioned one; in the case of __gvim__ this isn't really a smart thing because libperl.so doesn't really provide any version interface by itself. I used examples that I knew that would break compatibility in some cases. nmarques@p-nmarques:~> ldd /usr/bin/gvim | grep perl libperl.so => /usr/lib/perl5/5.16.0/x86_64-linux-thread-multi/CORE/libperl.so (0x00007eff0223a000) Also this looks quite promissing: nmarques@p-nmarques:~> chrpath --list /usr/bin/gvim /usr/bin/gvim: RPATH=/usr/lib/perl5/5.16.0/x86_64-linux-thread-multi/CORE Submitting a reworked package through OBS to fix the addressed issues would certainly go much further than dropping a ton of FUD on people. Christmas will be around in a blink, Merry Christmas. NM -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
participants (3)
-
Cristian Rodríguez
-
Linda Walsh
-
Nelson Marques