Bugzilla – Bug 403308
Dependency hell between Perl 5.8 and 5.10
Last modified: 2008-12-24 15:55:16 UTC
I would prefer if the Perl releases 5.8.8-76 (for 10.3) and 5.10.0-37.1 (for 11.0) can be installed in parallel by the YaST control centre. It seems to be very hard to fulfill the software requirements for the available tools at the moment. Can it be avoided to "fight" against so much parties? The needed file "libperl.so" is not found any more in the main directories after some installation attempts on my system. The locate command shows only the path "/usr/lib/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so".
so what problem do you have with deinstalling 5.8.8 on update?
You would have to keep not only libperl.so, but all the needed modules. I don't think we should support multiple perl versions, it causes too much trouble. Please recompile your software with 11.0's perl!
(In reply to comment #2 from Michael Schröder) > Please recompile your software with 11.0's perl! There are to much software components that reference still previous versions. I have not got control about updates for all of them. Simultaneous installation is usual for different processor architectures (16, 32, 64 ... Bit). I would also appreciate a similar distinction for programming languages like Perl, Java, TCL and PHP. Would you like to support easer version migration?
I don't see a way to achieve this because of the modules. You would need perl-TimeDate, perl-TermReadLine-Gnu, perl-libwww-perl, perl-Net_SSLeay,... in multiple versions. This doesn't work out, as updating a package kills with 'rpm -U' kills all other package versions. Maybe you have some ideas how to make this possible.
(In reply to comment #4 from Michael Schroeder) > This doesn't work out, as updating a package kills with > 'rpm -U' kills all other package versions. The installation procedure should also consider when to add a module, component or plug-in instead of a complete software replacement. Today I would expect that we are used to deep dependency trees with proper tools for release management.
Please tell that the folks that develop rpm...
It seems that Novell supports further software development in this area, don't you? ... http://news.opensuse.org/2008/06/05/sneak-peeks-at-opensuse-110-new-installer-with-stephan-kulow/
Why do you think that this changes the way rpm works?
Fundamental thoughts about installation procedures are contained in the OSGi service platform, too. http://en.wikipedia.org/wiki/OSGi#OSGi_Framework_Scope
Maybe, but this doesn't help us with the current limitations of our package system. Anyway, I'm closing this with WONTFIX as I don't see a feasible solution. If you really need the perl-5.8.8 libs, please install the perl-5.8.8 rpm, do a 'rpm -e --nodeps --justdb perl-5.8,8' so that rpm doesn't know any longer about it, and then reinstall the perl-5.10 package.
I would prefer that the software management knows all about required components (including old releases) for the active installation. It was achieved that KDE3 and KDE4 can be maintained in parallel by the package system. Why should it be not manageable to organise dependencies on a lower and deeper level for various programming languages?
Because of the modules. I won't put the perl version in the package name of >400 modules just to make you happy and confuse everyone else. Show me any other linux distribution that does that. Feel free to maintain your own perl + perl modules in the build service. (Don't forget python and ruby, too)
How are the chances that unique identifiers will be automatically added by the package build process? http://en.wikipedia.org/wiki/Universally_Unique_Identifier
Added to what? To the package name? Like perl-c00d0da9-5891-4d51-8c17-07eb5571a327? I don't think that people would like such a package. What you're asking for is to put the version in the package name, like we did for many libraries (e.g. libelf0 instead of libelf). Unfortunatelly it's not so easy for interpreters with lots of modules, as every module also would need the interpreter's version in the name.
Can proper name generation be automated for this use case?
Unfortunately, my try for a parallel installation to "/usr/local" from the current source files (http://www.cpan.org/src/perl-5.10.0.tar.gz) was not completely successful. I am still looking for ways to get YaST modules like network services configuration back to work.
I guess that the condition "perl >= 5.8.8" (instead of "perl = 5.10.0") will also be sufficient for more parts. How do you think about a fine-tuning for the requirement specification in the dependencies? Which software components will really require the newest release/revision?
Which configuration options should be added to a "local" Perl installation so that the following error message can be resolved? Where should any additional includes be placed for this programming language? Can't locate loadable object for module LibStorage in @INC (@INC contains: /y2update/modules /root/.yast2/modules /usr/share/YaST2/modules /usr/local/lib/perl/5.10.0/x86_64-linux-thread-multi-ld /usr/local/lib/perl/5.10.0 /usr/local/lib/perl/site/5.10.0/x86_64-linux-thread-multi-ld /usr/local/lib/perl/site/5.10.0 .) at /usr/share/YaST2/modules/LibStorage.pm line 11 Compilation failed in require. BEGIN failed--compilation aborted.
I don't think it makes any sense at all to maintain your own perl version. Good luck with all security updates and the like. Anyway, you should at least include the standard 5.10.0 search path, see 'perl -V'.
(And no, perl > 5.8.8 makes no sense, as the ABI typically breaks between versions)
I assume that there are (Perl) modules which do not depend on an application binary interface. How do you think about the chances for a parallel software installation that will be maintained by usual "prefix" directory handling of the package management?
By the way: The upgrade/update from the recently released openSUSE 11.1 DVD could move my installation to the current Perl version 5.10. The dependency resolution worked better for the affected software modules this time.