On 2014-12-03 15:39, Noel Butler wrote:
On 03/12/2014 21:57, Kevin A. McGrail wrote:
Sure, if that was truly the case nor would I, but if you are running that old
perl, there is plenty of stuff thats outdated, and not all of the goodness
gets backports, not just with perl, but with most other things.
I can't fight every windmill and changing how distros work re: versions of
perl is one I choose not to battle.
Regards,
KAM
Oh absolutely! But why is it SA's problem? Or for that mater, any up-stream's
problem if distro X wants to only maintain version_released_in_BC or some such,
I mean if, and lets take Redhat for example (not singling RH out, because debian
are just as bad, if not worse), they turn around and decide that RHEL since v5
will now be supported for 10 years, not 5, at what point do you draw the line
and say " well RH that's your problem "
N
OK, if RHEL elects to upgrade SA to 3.4.x and leaves perl as it was, they bought
their headaches. If SA provides specific updates to earlier versions so that
perl_version is declared and is numeric and the if clause works for each of the
old versions it makes the distro maintainers' job easy. If after that the distro
does not update AND SA posts word about the fix on the website VERY prominently
then the it becomes the distro maintainers who are the bad guys. Trying to Meet
them half way there seems like the polite thing to do. After all, it is a latent
SA bug that has come out to bite us. So we at least lead the horses to water.
They can choose to drink or not.
The alternate solution is rule updates for 3.4.x that contain the fancy rules
and separate rule updates for lower SA versions. If a sysadmin runs 3.4.2
against perl 5.8.6 he's bought his own problems. LTS distros don't tend to do
such upgrades.
{^_^}
