In SLES 11 SP3 SDK there is the perl-IPC-Run package of version 0.80 available. Unfortunately it is quite obsolete (reelased in 2006 while open suse 11 already contains 0.92 version) and thus fails in our internal script we use.
Would it be possbile to include the 0.92 version in SP3 SDK updates? There is also dependecy on perl-IO-Tty-1.10-24.1 as well.
I would like to avoid using the devel OpenSuse repository on Enterprise server environment.
When you say it is “quite obsolete” do you know what about your internal
script is failing due to its old version? I have never used this before,
and these forums are staffed only by volunteers in the community, but
perhaps there is a way to help for your case.
Is pulling down an updated version as a specific user on your system an
option from CPAN using the cpan command (or whatever other method)? I
recall having done this before when I needed something that was not
available, whether old or simply not included in the first place.
For an official response from SUSE you may want to submit an enhancement
request ( http://www.novell.com/rms ) or contact your sales
representative. Occasionally major/minor versions of packages can be
changed within the lifecycle of a single SLE version, though that is the
exception due to the preference for stability over the latest code.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below…
In SLES 11 SP3 SDK there is the perl-IPC-Run package of version 0.80
available. Unfortunately it is quite obsolete (reelased in 2006 while
open suse 11 already contains 0.92 version) and thus fails in our
internal script we use.
Would it be possbile to include the 0.92 version in SP3 SDK updates?
There is also dependecy on perl-IO-Tty-1.10-24.1 as well.
I would like to avoid using the devel OpenSuse repository on Enterprise
server environment.
Or there is any other way to resolve this issue?[/color]
Thanks for the advise. Does it mean such new built packages can be safely used in SLES? I am not very familiar with the repository policies in SLES, but I guess it is generally better to avoid mixing repos between OpenSUSE and Enterprise editions.
Or this case is an exception we can afford? I would be happy to know more about the best practice on this field, but have not found anything about it in documentation yet.
You know, I just want to avoid any problems with stability and later upgrades to new SLES release.
you’re definitely leaving “supported grounds”, but those packages (when provided explicitly for SLES-something) were built for the corresponding environment. Of course YMMV and you might consider it an untrusted source, but generally those packages have been very helpful to many SLES admins.
You’ll not be able to open related service requests under your SLES support contract and (generally speaking, not necessarily in this specific case) must be prepared to receive no support in other cases, when engineering can trace the cause back to such an unsupported package installed on your server. In other words, to stay on the absolutely safe side, avoid packages outside the distribution. But assuming you’re a responsible admin with experience and proper judgment, you can tell on your own if installing such a package is a simple add-on to your environment or affecting several other packages or even a replacement for a core component.
thanks for the explanation about the extra repository policies. I will take into account the limitation of support in such cases, although it sounds reasonable in my intended use to include this library as I have already tested it on our system.