New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Perl binary API compat between versions? #12830
Comments
From perl-diddler@tlinx.orgCreated by perl-diddler@tlinx.orgI ran into a problem with my distro recently where I wanted to It turns out, that they now link various files for their scripting There reason was that perl's binary API isn't stable enough so they It didn't matter how many scripts they broke by not allowing this -- Problem is that Suse (or specific individuals on the list) So what's the scoop? To enforce this various other binaries on As you may notice in this bug report, it's running with 5.16.2 -- The new version only included /usr/lib/perl5/<.../5.16.2/...> in it's Of course by doing so, I am completely unsupported, but since several Is the perl ABI really that unstable that venders have to lock the If this is a truely a problem, then something needs to change -- as Since I have reported this through my distro and have been told it's If this is a problem, it needs to be fixed. They claim it's caused Ideas? Fixes? Is perl really that different between versions If this is the case, is there any chance of firming up the API or Perl Info
|
From @jkeenanOn Sun Mar 03 00:01:31 2013, LAWalsh wrote:
I believe that many people take the approach that ... "The version of perl which your vendor (SUSE, in this case) supplies -- "In other words, rely on the system perl for the system's needs. Rely If you take this approach, you should not have to worry much about what Thank you very much. |
The RT System itself - Status changed from 'new' to 'open' |
From @LeontOn Sun, Mar 3, 2013 at 9:01 AM, Linda Walsh <perlbug-followup@perl.org> wrote:
Yes it is, mostly because various structs change internally. Perl has
No, it doesn't. Binary compatibility is sometimes hard and at other
The API is quite stable.
Have you tried perlbrew? It's quite awesome. Leon |
From @iabynOn Sun, Mar 03, 2013 at 03:41:17PM +0100, Leon Timmermans wrote:
And just to be clear, we guarantee binary compatibility across minor So an XS module compiled under 5.14.1 will continue working if the (There used to be a mechanism in place to try and provide binary -- |
From perl-diddler@tlinx.orgOn Sun Mar 03 06:00:55 2013, jkeenan wrote:
That's a bit the rub. My perl commands are the way my system does it's system administration At one point things were fine when they mostly did things in shell or C I expect the system utils... bind/named, squid, fsbackups, daily When sendmail invokes local delivery, it wouldn't be prudent to try to |
From perl-diddler@tlinx.orgOn Sun Mar 03 06:42:04 2013, LeonT wrote:
I did... caused complete chaos, when root and daemon processes went to It took me a bit of time to figure out why none of my changes were |
From perl-diddler@tlinx.orgOn Sun Mar 03 11:05:11 2013, davem wrote:
I think this is where I have accidently tended to be safe. I'd include however, at the first sign of a problem, (or often, regardless, after a Most of my perl stuff didn't have binary interfaces, but some use libs I think that's the most likely reason my upgrading my system's perl The problem has arisen with suse because they tying non-perl utils with It *used* to be the case (before SuSE 12.1 (~ 1-1.5 years old), that FWIW, I got around various of these probs by recompiling gvim to use I.e. I wanted to verify that their version actually was able to They don't support user's building rpms on their own systems anymore -- Anyway... they seem to be under the impression that even minor releases From my perspective, if their system programs need a special, fixed MS solved this by allowing side-by-side libs and applications to link Bottom line -- from my perspective, is that I have root and other users
Was that done dynamically if the version numbers differed, or did it Similarly, (maybe?), in the linux kernel when tracing is active, it FWIW though -- they aren't even assuming that minor versions are compat. Thanks! (the microsoftization of linux is proving quite painful)... |
From @bulk88On Sun Mar 03 14:06:49 2013, LAWalsh wrote:
Side by side often does NOT work in practice. A C++ object/pointer is
You always call a *portable* C function, AFAIK the function returns the
I can't think of an analogous feature on Windows. You are describing a
Can someone explain what the *technical* complaint or feature request Are some vendor linux perl scripts in pure perl hard coded to check -- |
From perl-diddler@tlinx.orgOn Sun Mar 03 17:00:22 2013, bulk88 wrote:
Different mechanism are used in different place to provide redundant 1) rpm checks:
2) run-time checks in some programs:
3) modifications of the INC path to exclude the current perl version:
There may be other methods, but those are 3 I've encountered. |
From @TuxOn Mon, 04 Mar 2013 01:20:56 -0800, "Linda Walsh via RT"
I run openSUSE since version 7 and never ran into the trouble you For my personal stuff I only use system-perl to verify that my CPAN My system perl is not the perl installed from the main SUSE repo, but (change the release number to match your distribution) # zypper ar --rfresh http://… perl-12.2 -> View repositories -> Choose perl-12.2 -> Switch system packages # zypper ve
Not installed. Never needed those
gvim-7.3.566-1.5.1.i586 runs flawless on my laptop. Though I must admit
Config 'root' not found. so I guess I never needed that one either # zypper ve Dependencies of all installed packages are satisfied. -- |
From perl-diddler@tlinx.orgOn Mon Mar 04 02:08:49 2013, hmbrand wrote:
http://download.opensuse.org/repositories/devel:/languages:/perl/openSUSE_12.2 ^^^^ right there is the problem. I am running on openSUSE 12.1. It shipped with perl-5.14 -- and much trouble can result if it is
Most of suse's yast/yast2 is written in perl, so it's hard to
I bet you it does run fine. It requires 5.16 and you are running I had to reinstall the gvim from my current distro to reproduce the
If you don't run yast, you probably aren't going to run it's modules. Many of the modules use python now -- they've been moving away from perl
5.16.0 is the version that comes with 12.2, so you're fine.
I tend to build my own products from sources and run newer versions Been doing so since before I was on suse because vendors optimized for The point is not about whether or not I can get around it, but the fact |
From @doughera88On Sun, 3 Mar 2013, Dave Mitchell wrote:
More details are in the INSTALL file under the section: =head1 Coexistence with earlier versions of perl 5 -- |
From @doughera88On Mon, 4 Mar 2013, Linda Walsh via RT wrote:
That sounds like an error in the packaging system.
Again, if that's a system-supplied gvim, then this sounds like an error in
That sounds truly odd. Why on earth would they exclude the current perl
I'm sorry, but I have no idea what 'yast' or 'reipl' are, so I have no I'm sorry to be dense, but I actually have no idea what specific bug in Could you please restate the problem very briefly in terms that someone Thanks, -- |
From @TuxOn Mon, 04 Mar 2013 04:23:49 -0800, "Linda Walsh via RT"
As I stated just one line down: change it!
If you want the system perl upgraded (god may know why), you could go # zypper ar --refresh http://download.opensuse.org/repositories/home:/doiggl/openSUSE_12.1 doiggl-perl-12.1 Still not the way I would interfere with system perl, but at least now # zypper ve is HIGHLY recommended after these actions
And *what* in those scripts *needs* 5.16.x that cannot be done in
Yep :)
I use yast2 quite often: e.g. it is a very easy interface if one wants
No, I run 5.16.2, but not from /usr/bin
So, perl is not important enough to buil;d from scratch? As said: let I do the same for my daily set of tools: elvis, xterm, tcsh, perl, git,
if perl is on that list, I don't see the reason for this ticket at all
Just curious: did you actually noticed any improvement?
questionable, but what should withhold them ?
Not SUSE's *problem*. It is their decision, and not resulting in There is a BIG difference in releasing/shipping something broken, or
-- |
From perl-diddler@tlinx.orgH. Merijn Brand via RT wrote: http://download.opensuse.org/repositories/devel:/languages:/perl/openSUSE_12.2
The problem then becomes when those modules require updates -- they Having to maintain some special list of "downrev'ed modules from SuSE,
That wouldn't work due to all the interlock checks in 12.1 for perl 5.14.0.
Dell is currently compat with SUSE 11, maybe (the corporate version), They each need different libraries to run on and manage 1 suse system. A "zypper ve" spews over a page worth of fails for the 1st question (and Having to support various external utils that don't update every 6-9
You have that question backwards. What do they need in 5.14.2 that can't be done in 5.16.2? I want I would understand if I wanted to downgrade, that there might be
My statement/assumption was based on your statement that you didn't ever yast2 requires yast2-perl-bindings: If you are using yast2, you are using yast2-perlbindings.
I said it and the kernel were among the tools on the list? What gives
That doesn't work -- I need to upgrade the perl that is used by the
More so with x586 v. Pentium-II/III optimizations -- 10-15%
LESS functional --- I use that functionality and have to > 10 years. They claim it's because of perl instabilities ... that's the point I don't need a lecture on how to manage my system when it's been I have generally done system-level development, not perl-development. As such, when I make changes, I do so at the system level. Arguably, with today's HW, I could do so in a VM, but *if* I could Suse switched to doing sterile-env build& test in the 12.x series. That's when I started being plagued by incompat problems -- because |
From @doughera88On Mon, 4 Mar 2013, Linda Walsh via RT wrote:
As far as I can tell, this ticket can be closed, since there is no bug in -- |
From @rurbanThe issue is valid, but I know of no other distro other than mine, You, resp. upstream need to change the paths to omit the PERL_SUBVERSION, E.g. this is my @INC on cygwin with a proper upgrade strategy: perl -V: |
From @jkeenanOn Wed Mar 06 09:46:02 2013, doughera wrote:
Agreed; closing.
... but not here. It's not an appropriate subject for RT or for P5P. A Thank you very much. |
@jkeenan - Status changed from 'open' to 'resolved' |
From @doughera88On Wed, 6 Mar 2013, Reini Urban wrote:
Tests of the current 5.14 and 5.16 mainteance release candidates would be -- |
From @rurbanOn Mar 6, 2013, at 8:43 PM, Andy Dougherty <doughera@lafayette.edu> wrote:
I did it for 5.14 already. 5.16 is considered too insecure to be releasable |
From @iabynOn Thu, Mar 07, 2013 at 06:47:19AM -0600, Reini Urban wrote:
Considered insecure by Reini. Considered secure by everyone else. http://www.nntp.perl.org/group/perl.perl5.porters/2012/10/msg193433.html -- |
From perl-diddler@tlinx.orgOn Thu Mar 07 07:24:40 2013, davem wrote:
Having been in OS security for some time, I have found that most buffer I remember a specific find by me regarding an asymmetric change in |
From @rurbanOn Thu, Mar 7, 2013 at 9:15 AM, Dave Mitchell <davem@iabyn.com> wrote:
As far as I remember I never detailed my 5.16 concerns publicly. It were not I thought it would be too risky, so I brought that up at in private, on But saying that I am spreading FUD is not helping us on this issue. |
From @iabynOn Thu, Mar 07, 2013 at 03:00:56PM -0600, Reini Urban wrote:
Ok. Please provide a description of a specific change of behaviour -- |
From @iabynOn Thu, Mar 07, 2013 at 09:52:54PM +0000, Dave Mitchell wrote:
(not to be Cced to p5p of course). -- |
From @rurbanOn Thu, Mar 7, 2013 at 3:54 PM, Dave Mitchell <davem@iabyn.com> wrote:
I initially wrote yet another long email to explain my old 5.16 But since I have not much to add to my initial complaint to You are still saying that 5.16 is finally binary safe, and I'm still So: Much more nul-names in modules and introspection dumpers need to be I would be happy to fix the security issues by enabling warnings. |
From @iabynOn Thu, Mar 21, 2013 at 02:43:28PM -0500, Reini Urban wrote:
Well, it is of course your prerogative not to provide an example; however, One consequence of that is that we are going to be less minded to accept a -- |
From @avarOn Sun, Mar 3, 2013 at 9:01 AM, Linda Walsh <perlbug-followup@perl.org> wrote:
I think everyone in this thread is kind of missing the point of this It really has nothing to do with perl in particular, but seemingly It doesn't matter if you have a 100% binary compatible software That's the whole point of using a Linux distribution at a given As others have pointed out in this thread: If your needs are different |
From perl-diddler@tlinx.orgOn Thu May 09 10:11:40 2013, avarab@gmail.com wrote:
I'm not sure if I am confused about what you are saying, or not. While I have little issue that upgrading from 5.14.X to 5.16.X would But upgrade perl from 5.16.0 to 5.16.1 or .2 -- and you start getting Perhaps you were trying to say that it's reasonable for vendors not to It's not entirely clear which of those, if any, you were referring to. |
From @avarOn Thu, May 9, 2013 at 10:18 PM, Linda Walsh via RT
Your initial E-Mail mentions difficulties upgrading from 5.14 to 5.16 But as for them blocking minor release upgrades that seems But in any case this is a thing to take up with SuSE. They'll know |
Migrated from rt.perl.org#117015 (status was 'resolved')
Searchable as RT117015$
The text was updated successfully, but these errors were encountered: