Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

classic Classic list List threaded Threaded
36 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

L A Walsh
Felix Miata wrote:
> On 2013-02-07 05:27 (GMT-0800) Linda Walsh composed:

> I won't be guessing. If you have Factory enabled on a 12.1 system I'm
> outa here.
>
> If I want a package from an alien repo, I download the package and
> install locally if it will let me without complaining about incompatible
> deps. Sysvinit-init except from a 12.1 repo isn't likely to be anything
> more than a problem creator. Mixing basesystem packages from different
> release versions can't be good for much other than making trouble.
----
Now I remember how this started.

This used to be possible -- load newer glibs they'd still be compat
with older ones, and then could load apps you needed newer versions of.

My deal breaker was perl 5.16.[012]  had some unicode fixes in it that I needed,
but if you check the logs on here I was complaining about not being able to build
perl5.16.1 last summer --- was told I needed to use a clean system to build....

Well tried that but that didn't work either and no one seemed willing to fix the
problem
that I was told had messed up my home directory so I couldn't log in.  It was a
short lived
problem where trying to signup and login only console registration, and not from
the web,
resulted in an incomplete or misconfigured directory setup.

Anyway, long story, still not solved -> lead me to needing to install from 12.2,
Around then I started asking why all the packages were tightly tided to gether
now so you
couldnl't update something like perl without all of yast breaking -- it's all
tied to
features in 5.14.

Asked about that and similar issues with glibc, -- was told that older apps
should run on newer systems as long as they versions aren't too far apart, but
new stuff on old machines was
a definite no go.

That's how I've always understood it...but someone built all of the yast rpm's with
specific older versions of things -- ALOT of packages claim they will only work
with
1 version of software -- that didn't used to be the case.

But that's why I've had all theseproblems ... no way to get from here to there...

ARGGGG!!!!

Effectively I was told I couldn't use the new perl unless I upgraded everything
which
was ridiculous!



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Cristian Rodríguez-2
El 11/02/13 15:26, Linda Walsh escribió:

> But that's why I've had all theseproblems ... no way to get from here to
> there...

We have explained to you ad-nauseum that there is nothing wrong with
libc, whose compatibility promise is been kept under the same constrains
for a decade or more.

Components other than libc have their own binary compatibility policies
if any. those who dont publish any document stating a policy on this
matter *must* me assumed like there is none and that ABI/API may change
at will.

Cheers.





--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

L A Walsh
Cristian Rodríguez wrote:

> El 11/02/13 15:26, Linda Walsh escribió:
>
>> But that's why I've had all theseproblems ... no way to get from here to
>> there...
>
> We have explained to you ad-nauseum that there is nothing wrong with
> libc, whose compatibility promise is been kept under the same constrains
> for a decade or more.
>
> Components other than libc have their own binary compatibility policies
> if any. those who dont publish any document stating a policy on this
> matter *must* me assumed like there is none and that ABI/API may change
> at will.
---
        YAST belongs to openSuSE..

        I wanted to upgrade my perl, but yast in 12.1 claims it
requires perl5.14 and won't work unless I downgrade.

        This never used to be the case.

        Did OpenSuSE change policy to lock all of their own
apps into each version so no versions can be used?  That would be
a really bad policy -- since, more than once, on upgrade, I've found
a new version of "X" either doesn't work for me, or is going to take some
time and effort to upgrade (samba 3.5.x->3.6.x required remaking the user
database -- have seen that on the samba list from others as well).

        Sometimes it's samba, sometimes, it's ng-syslog,
nearly every upgrade has had some issues.

        Gvim -- was another one -- built specifically to perl-5.14.so.
But if you build it as generic "perl.so", then gvim works fine with
multiple versions.  Same applied for python and and another script
language -- I ran into some issue with ruby (which I found a bug
report on, and a workaround, but was too complicated and I was in
rush, so built w/o ruby...  The rest are loaded at run time -- not
load time.  So if they are not on the machine, at least the person
can run the editor.   But more importantly -- the way it is in the
distro -- you can't upgrade perl.

        Suse had never locked specific versions of tools before 12.1,
but did in 12.1 -- nearly every binary is linked with every other binary
by name+version -- not just name as it used to be.

        Many (Most?) RPM's have had "pre-reqs" changed from
some *minimum* version of a package to *exact equality*.

        As someone who constantly is upgrading software, having everything
locked together, really is broken.

        Can this be fixed (obviously not overnight, but some policy needs
to be reverted)...

        Neither the yast nor the gvim changes come from upstream --
they are suse changes.



.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Cristian Rodríguez-2
El 11/02/13 21:11, Linda Walsh escribió:

>      YAST belongs to openSuSE..
>
>      I wanted to upgrade my perl, but yast in 12.1 claims it
> requires perl5.14 and won't work unless I downgrade.
>
>      This never used to be the case.

Because Yast had and continue to have bugs, one of those bugs was the
lack of strict dependency of perl versions.


>      Did OpenSuSE change policy to lock all of their own
> apps into each version so no versions can be used?

No, it is just software that links to libperl must require the _exact_
perl version otherwise it wont even start correctly.


>      Suse had never locked specific versions of tools before 12.1,
> but did in 12.1 -- nearly every binary is linked with every other binary
> by name+version -- not just name as it used to be.

There were lots of bugs, explicit dependencies were added to avoid
breaking systems on upgrade.

>      Can this be fixed (obviously not overnight, but some policy needs
> to be reverted)...

Nope, at least not until perl provides properly versioned DSOs upstream.
The fact that in your experiment applications worked with multiple
versions is pure luck.





--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

L A Walsh
Cristian Rodríguez wrote:

> El 11/02/13 21:11, Linda Walsh escribió:
>
>>      YAST belongs to openSuSE..
>>
>>      I wanted to upgrade my perl, but yast in 12.1 claims it
>> requires perl5.14 and won't work unless I downgrade.
>>
>>      This never used to be the case.
>
> Because Yast had and continue to have bugs, one of those bugs was the
> lack of strict dependency of perl versions.
----
        I've Never had problems with yast's interactions w/perl
and I'm always running non-standard versions.  That goes back 10 years...
It's not until you add the version numbers that I have problems and things
don't work.

        I don't call that dumb luck --- ensuring that it won't
work, though, that's sabotage...

        There's a been a bad trend in computers that's grown over the past
several years, and that's to default to broken, rather than giving
the user anything.

        There are some security scenarios (many) where that is appropriate,
but on a home system -- it's usually not.

        I the system won't come up due to deliberate sabotage in version
locking, then I can't fix it.  Before 12.1, I used to be able to boot
off of the 11.1 rescue disk (and this was a change in glibc -- I'm not
saying the trend toward breakage is unique to suse).

        When computers first came out, the people who programmed them
TRIED to make them friendly and tried to make them helpful.  A PL/I
compiler back in my student days used to make lots of assumptions about
what you meant if you got wrong syntax ... IN PROGRAMS -- and 90% of the
time it was right!..   Even in the face of errors, after it applied
what it thought were the right corrections (trivial things like missing
semicolons and such), it would attempt execution -- and you usually got
a working (for some definition of such) program.

        Now, computers are being constructed to be hostile to the users
-- be unfriendly and difficult to use.   Just like this -- I can't mix
and match versions like I have for over 10 years.. (within thought out
reasons...but I majored in computer science, so not average user)...

        you are taking away the flexibility of unix.

        it was always a good and bad thing that rm -fr / just went off
and did it -- you figured not to do things like that.

        Now the trend is to disable user control and flexibility -- turn
them back into passive receivers.


>
>>      Can this be fixed (obviously not overnight, but some policy needs
>> to be reverted)...
>
> Nope, at least not until perl provides properly versioned DSOs upstream.
> The fact that in your experiment applications worked with multiple
> versions is pure luck.
---
        That is pure bull...
        Gvim has been built that way for several years on Windows
and has had no major problems.

        Now if you have linked built code that you expect to be
"hard linked" at runtime, those references can be a problem,
but if you use the dynamically loaded interface, it's a lower
common denominator, but it works.

        The Vim make/build file supports building with run time libraries
but suse chooses not to use it.

        Vim does the same thing with python and the other scripting languages it
supports.   It's not dumb luck -- it was designed that way.

        please NOTE -- this is for the dynamicly, run-time loaded library,
not the one that is autolinked by 'ldd'.

        Are we talking about the same thing?

        linux people don't seem to get run-time dynamic linking that much.
Unix people did it -- and windows does it "delayed loading libraries"...but
linux -- not so much...and it's a shame.  those systems that use such are
generally more flexible and resilient to problems in the field -- because
they know enough not to expect things, but are written to check for things
being there -- and if not, then not using them.

        Problem is programming is getting harder and harder as time goes on, and
programmers are continuing to lower the bar for what they will allow and produce
-- you want user friendly?   You want it to correct your mistakes and just work?
It's certainly a bad time computer users/owner... capitalists figured out
that making software that worked well and long and didn't need upgrades was
bad for business -- requiring a compute replacement of all software with every
release?

        Perl is especially bad for you to harsh on -- they are SO conservative about
backwards compatibility -- I'd love to see what some of the yast issues were
that regard version issues.  They maintain strict backwards compatibility for
ages...and change slowly if at all.

        What parts of yast had problems? --- that would have been problems
if you did run-time dynamic loading?

        As for perl's latest build scripts -- it **warned** me of using
the generic libperl.so name that's been used for years -- BECAUSE of the
minority of people that have problems.  I'm frustrated because when these things
break, I usually know how to fix them -- but when everything is interlocked and
taking out 1 piece causes everything to break...

        That's a setup for major pain.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Cristian Rodríguez-2
El 11/02/13 23:11, Linda Walsh escribió:

.


>      Vim does the same thing with python and the other scripting
> languages it supports.   It's not dumb luck -- it was designed that way.
>
>      please NOTE -- this is for the dynamicly, run-time loaded library,
> not the one that is autolinked by 'ldd'.
>
>      Are we talking about the same thing?
>
>      linux people don't seem to get run-time dynamic linking that much.

No. we get it pretty well, it is just we must not use it when building a
distribution and when it is the case of system libraries.

See, all dependencies on system libraries must be known by the package
manager, the build system etc.. so, all needed libraries get installed
or recommended and the build system knows when and how to rebuild
stuff.. problem is.. RPM does not account for dynamically loaded
libraries/modules.. so esentially you are on your own.

> Unix people did it -- and windows does it "delayed loading libraries"...but
> linux -- not so much...and it's a shame.

NO, it is designed for ease on distribution maintenance.

  those systems that use such are
> generally more flexible and resilient to problems in the field -- because
> they know enough not to expect things, but are written to check for things
> being there -- and if not, then not using them.

There is nothing resilent and flexible on using this mechanism in the
context of a huge distribution, it is just a recipe for imminent disaster.

   I'm frustrated because when
> these things break, I usually know how to fix them -- but when
> everything is interlocked and taking out 1 piece causes everything to
> break...
>
>      That's a setup for major pain.
>

I believe you are looking for a BSD system or a source based distribution.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Roger Oberholtzer
In reply to this post by L A Walsh
On Mon, 2013-02-11 at 18:11 -0800, Linda Walsh wrote:

> linux people don't seem to get run-time dynamic linking that much.
> Unix people did it -- and windows does it "delayed loading libraries"...but
> linux -- not so much...and it's a shame.  those systems that use such are
> generally more flexible and resilient to problems in the field -- because
> they know enough not to expect things, but are written to check for things
> being there -- and if not, then not using them.

Hmm. I would suggest that the Linux understanding of run time dynamic
linking is rather the opposite of what you think.

When I make a library on Linux (GNU tools), I can leave things
undefined. All functions do not need to be resolved when the library is
made. They will be resolved (hopefully) when the process using the
library loads the library. At that time, any remaining dynamic linking
is done.

This is in strict opposition to my experience on, say, Windows (GNU and
MS tools act the same), where libraries need to have all symbols
resolved before the library will be made. The Windows process loader
will not resolve things dynamically. The DLL, AND the location in the
DLL (a bane to all Windows developers) must be determined when libraries
and apps are made. There is no run time dynamic linking when the process
loads. Of course, you can do your own dynamic linking after the app
loads, but the process loader will not do this to get the app started.
This is one reason why Windows apps load faster. They are not dynamic at
this stage in their life.

The Linux method in fact allows run time dynamic linking to have great
flexibility in how the symbols get resolved, while the Windows method
allows no such flexibility. This also means that Linux has a greater
chance of a mistake when library versions do not match.

In your case, the problem is surely as stated: Perl is doing a crap job
of maintaining application binary compatibility - which is a
non-optional required property if the libraries expect to provide
backward compatibility. The different versions of their libraries are
not backwards compatible (read as 'new versions do not provide old
features'). This lack of ABI compatibility in the Perl libraries results
in the app developer being forced to require that certain versions of
the library are used. The fact that earlier version of openSUSE software
worked was perhaps luck. It depends on what Perl choose to change. The
extent of non ABI compatibility is their decision.

I think that openSUSE should instead be encouraged to find these ABI
compatibility violations (which are seldom documented by the developer
and thus lots of work to discover) and take the corrective actions to
make openSUSE better. I am sure that they would be happier if Perl had
some sort of ABI compatible method. But if Perl don't, then they must
take the next best action.

Complaints should surely be directed to the cause of the problem (Perl)
and not the victim (openSUSE).


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Dave Howorth
Roger Oberholtzer wrote:

> In your case, the problem is surely as stated: Perl is doing a crap job
> of maintaining application binary compatibility - which is a
> non-optional required property if the libraries expect to provide
> backward compatibility. The different versions of their libraries are
> not backwards compatible (read as 'new versions do not provide old
> features'). This lack of ABI compatibility in the Perl libraries results
> in the app developer being forced to require that certain versions of
> the library are used. The fact that earlier version of openSUSE software
> worked was perhaps luck. It depends on what Perl choose to change. The
> extent of non ABI compatibility is their decision.
>
> I think that openSUSE should instead be encouraged to find these ABI
> compatibility violations (which are seldom documented by the developer
> and thus lots of work to discover) and take the corrective actions to
> make openSUSE better. I am sure that they would be happier if Perl had
> some sort of ABI compatible method. But if Perl don't, then they must
> take the next best action.
>
> Complaints should surely be directed to the cause of the problem (Perl)
> and not the victim (openSUSE).

I'm not sure what you're complaining about Roger. Perl applications are
written in Perl, they shouldn't have binary dependencies.

Perl's backwards compatibility policies are set out at
http://perldoc.perl.org/perlpolicy.html

The perl implementation in openSUSE, and in other distros I'm aware of,
allows for multiple versions of perl itself and multiple versions of
modules (libraries) for each version. Because there are system
dependencies (e.g. YaST) on the particular version of perl and modules,
it is very important not to try to simply overwrite the existing system
perl. Everything is set up to make that as simple as possible.

New modules can be installed either via YaST, which will result in
versions compatible with system applications, or via CPAN which will
result in alternate versions (usually newer). The system and alternate
versions co-exist quite happily. YaST will continue to use the system
versions; your programs can use the newer versions if you wish.

Alternate versions of perl itself can be installed but you must *not*
try to change the system's perl. Use perlbrew http://perlbrew.pl/ or a
homebrew layout similar to the description at
http://stackoverflow.com/questions/1289564/how-should-i-install-more-than-one-version-of-perl

And yes, it is important to make sure that each application program is
written and tested in a particular environment. If you randomly upgrade
the environment, things may break.
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Roger Oberholtzer
On Tue, 2013-02-12 at 11:08 +0000, Dave Howorth wrote:

> I'm not sure what you're complaining about Roger. Perl applications are
> written in Perl, they shouldn't have binary dependencies.

Not a complaint. I was trying to support what the openSUSE guys have
done.

Re Perl (and similar libs): This is not about Perl scripts. It is about
programs that access Perl via a compiled library. If you link with
version X, you are safest running only with that version. The complaint
was that, previously, openSUSE apps like YaST did not get built so they
required a specific libperl version. That has now been changed as Perl
libs are not backward ABI compatible. This means that YaST requires a
specific Perl version. Which is, I guess, the 'system' Perl. You are not
free to change that as Perl provides no mechanism to maintain ABI
compatibility in a single Perl install. So you cannot have one system
Perls that is ABI compatible with previous versions.

> Perl's backwards compatibility policies are set out at
> http://perldoc.perl.org/perlpolicy.html

Where they say they do not do backward compatibility. Which makes the
currently described limit necessary.

Anyway, I was not complaining.


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Anton Aylward-2
In reply to this post by L A Walsh
Linda Walsh said the following on 02/11/2013 09:11 PM:
> I don't call that dumb luck --- ensuring that it won't
> work, though, that's sabotage...

Here you go, Linda, a signature block for you to use when posing to the
list.

Its a corollary to Clarke's Third Law:

        "Any sufficiently advanced level of incompetence is
         indistinguishable from malice".


--
My definition of an expert in any field is a person who knows enough
about what's really going on to be scared.
    P. J. Plauger, Computer Language, March 1983
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Cristian Rodríguez-2
In reply to this post by Roger Oberholtzer
El 12/02/13 06:48, Roger Oberholtzer escribió:

> When I make a library on Linux (GNU tools), I can leave things
> undefined.

Yes you can, however you should not do this unless you have a very
compelling reason or we, packagers will hate you foreva :-)

Fortunately the compiler and the linker currently makes much harder to
do it wrong :-D

> I think that openSUSE should instead be encouraged to find these ABI
> compatibility violations (which are seldom documented by the developer
> and thus lots of work to discover) and take the corrective actions to
> make openSUSE better.

That's the holy grail, kinda like living in the world of happy thoughts
and riding unicorns .. however that's not how reality operates
unfortunately.even something at a "smaller scale" such as the LSB, which
tries to define an "standard" ABI for a subset of components is gonna
fail (or lets say has failed) miserably.




--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Roger Oberholtzer
On Tue, 2013-02-12 at 17:30 -0300, Cristian Rodríguez wrote:
> El 12/02/13 06:48, Roger Oberholtzer escribió:
>
> > When I make a library on Linux (GNU tools), I can leave things
> > undefined.
>
> Yes you can, however you should not do this unless you have a very
> compelling reason or we, packagers will hate you foreva :-)

We do not do this. Our Makefiles are used to generate both Linux and
Windows binaries (MinGW). So they do what is needed to work for both.
So, we specify libraries when making libraries.

> Fortunately the compiler and the linker currently makes much harder to
> do it wrong :-D

Indeed.


Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

L A Walsh
Roger Oberholtzer wrote:

> On Tue, 2013-02-12 at 17:30 -0300, Cristian Rodríguez wrote:
>> El 12/02/13 06:48, Roger Oberholtzer escribió:
>>
>>> When I make a library on Linux (GNU tools), I can leave things
>>> undefined.
>> Yes you can, however you should not do this unless you have a very
>> compelling reason or we, packagers will hate you foreva :-)
>
> We do not do this. Our Makefiles are used to generate both Linux and
> Windows binaries (MinGW). So they do what is needed to work for both.
> So, we specify libraries when making libraries.
---
If you want to build for portability, that's the way to go.

If you want Tivoize a system that makes it difficult or impossible for
a user to upgrade, but can be upgraded by the "suse-build-tools" (if
you have access to them -- for some people they don't work, but that's
presuming your access wasn't cut off for some reason), then you
use signed binaries that all interlink with versions now, but later,
checks of the signatures.

MS already has this option -- but it's not ever used with user
systems that I know of.  In fact MS has gone the extra mile to make
sure that multiple versions of the same libraries can live side by side,
because in real life -- people are still running XP apps on Win 7
and probably win8.

Opensuse is guaranteeing the obsolescence of each release by making it
binary incompatible with previous releases.

Christian said this:

See, all dependencies on system libraries must be known by the package manager,
the build system etc.. so, all needed libraries get installed or recommended and
the build system knows when and how to rebuild stuff.. problem is.. RPM does not
account for dynamically loaded libraries/modules.. so esentially you are on your
own.
---
Sounds like a bug in RPM.  In fact, the biggest bug in RPM, appears to be
your claim that you can't have multiple version of the same software installed
on a machine and have software link with the appropriate version at run time.

I don't see why you don't hard code the load time library version number you
want into the link phase.  Just stop linking with libc.so.6 or libperl.so

Why can't you do this:
-rwxr-xr-x 1  1960896 Jul 15  2012 /lib64/libc-2.15.so*
-rwxr-xr-x 1  1966974 Oct 11 23:35 /lib64/libc-2.16.so*
-rwxr-xr-x 1 10160535 Jan 16 17:24 /lib64/libc-2.17.so*
lrwxrwxrwx 1       12 Jan 30 02:15 /lib64/libc.so.6 -> libc-2.17.so*
---
Let multiple version of a library install -- and if your code need a specific
version, then link to the non-generic name.

Same with perl.

You would be loads better off than you are now -- because now, you are embedding
those specific versions into each generic and linking all your apps with
the generic name, guaranteeing that a user can't update *their* system libraries
without the distro having a hissy-fit.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

L A Walsh
In reply to this post by Dave Howorth
Dave Howorth wrote:
> New modules can be installed either via YaST, which will result in
> versions compatible with system applications, or via CPAN which will
> result in alternate versions (usually newer). The system and alternate
> versions co-exist quite happily. YaST will continue to use the system
> versions; your programs can use the newer versions if you wish.
---
        My programs are run by root and other User id's.
>
> Alternate versions of perl itself can be installed but you must *not*
> try to change the system's perl. Use perlbrew http://perlbrew.pl/ or a
> homebrew layout similar to the description at
----
        I was shocked on a recent upgrade to find my perl mod upgrades
being redirected to my home dir (without notice).

        I couldn't figure out why my scripts worked for me but not
for other users and root.... then I noticed the garbage cluttering up
my home dir...*cute trick*.

        I write my scripts to so system administration.  What else do you
use perl for?  If it doesn't run at the system level, they don't run.

Cristian Rodríguez's last name no longer comes across as:
"Cristian Rodr��������������������������������"

BECAUSE I am running perl5.16.1.

You are telling me that I should go back to 5.14 for that?

(It's been broken since 5.8.1 when they broke unicode support by
default).

But you are telling users that they can't fix their systems and have
to take only things given from suse with appropriate internal interlocking
version deps ....

That is not an open system.   That's a closed system.

Is suse being "ClosedSuse"... sure sounds like it.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Dave Howorth
Linda Walsh wrote:

> Dave Howorth wrote:
>> New modules can be installed either via YaST, which will result in
>> versions compatible with system applications, or via CPAN which will
>> result in alternate versions (usually newer). The system and alternate
>> versions co-exist quite happily. YaST will continue to use the system
>> versions; your programs can use the newer versions if you wish.
> ---
>     My programs are run by root and other User id's.
>>
>> Alternate versions of perl itself can be installed but you must *not*
>> try to change the system's perl. Use perlbrew http://perlbrew.pl/ or a
>> homebrew layout similar to the description at
> ----
>     I was shocked on a recent upgrade to find my perl mod upgrades
> being redirected to my home dir (without notice).

Perhaps you should have RTFM before running the commands then. It will
tell you how to avoid such self-inflicted problems. And the time you
take reading may slow down the nonsense you post to this list if we are
lucky.

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Roger Oberholtzer
In reply to this post by L A Walsh
On Thu, 2013-02-14 at 03:40 -0800, Linda Walsh wrote:

> I don't see why you don't hard code the load time library version number you
> want into the link phase.  Just stop linking with libc.so.6 or libperl.so
>
> Why can't you do this:
> -rwxr-xr-x 1  1960896 Jul 15  2012 /lib64/libc-2.15.so*
> -rwxr-xr-x 1  1966974 Oct 11 23:35 /lib64/libc-2.16.so*
> -rwxr-xr-x 1 10160535 Jan 16 17:24 /lib64/libc-2.17.so*
> lrwxrwxrwx 1       12 Jan 30 02:15 /lib64/libc.so.6 -> libc-2.17.so*

It is not enough to make the link. The link just makes compiling easier.
The magic happens whrn /lib64/libc-2.17.so /lib64/libc-2.16.so are made.

>From the ld man page:

       -h name
       -soname=name
           When  creating an ELF shared object, set the internal DT_SONAME field to the specified name.  When an exe-
           cutable is linked with a shared object which has a DT_SONAME field, then when the executable  is  run  the
           dynamic  linker  will  attempt  to load the shared object specified by the DT_SONAME field rather than the
           using the file name given to the linker.

Then, the libXX folk must ensure that the 2.15 version of their library
is ABI compatible. When that changes, they should bump the version. Both
libraries can be present on the system, providing different ABI
versions. Any binary simply uses the one it was built with, independent
of what any other bins may be up to. But this only works if the -h
option was used when the library was built - and that the version
numbers are truly reflecting ABI compatibility.

Is Perl doing this properly? I do not mean that they have libs with
different version numbers. But are those numbers properly tracking ABI
compatibility? It sounds like openSUSE feel this is not the case.



Yours sincerely,

Roger Oberholtzer

Ramböll RST / Systems

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Cristian Rodríguez-2
In reply to this post by L A Walsh
On 02/14/2013 08:40 AM, Linda Walsh wrote:

> Opensuse is guaranteeing the obsolescence of each release by making it
> binary incompatible with previous releases.

OK, I'm done with you Linda, I explained to you how things work, why
they work that way, and the tradeoffs involved between making a
distribution easy to use,upgrade and develop under the assumption users
will not try to do insane things like what you are clearly doing and
must assume you are on your own.

But you simple do not want to listen and keep making ridiculous, wrong
and unsupported assertions about pretty much everything.




--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse 12.1 apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Anton Aylward-2
In reply to this post by L A Walsh
Linda Walsh said the following on 02/14/2013 06:52 AM:
> Is suse being "ClosedSuse"... sure sounds like it.

There are other distributions you can use.

--
"In a word -- im-possible!"
"That's two words," said Dibbler.
(Moving Pictures)
--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

L A Walsh
In reply to this post by Cristian Rodríguez-2
Cristian RodrC-guez wrote:
> On 02/14/2013 08:40 AM, Linda Walsh wrote:
>
>> Opensuse is guaranteeing the obsolescence of each release by making it
>> binary incompatible with previous releases.
>
> OK, I'm done with you Linda, I explained to you how things work, why
> they work that way, and the tradeoffs involved between making a
> distribution easy to use,upgrade and develop
----
        You are not making it easy for users to use, upgrade and develop
on.  You are making it easier for yourself at the expense of users.


> under the assumption users
> will not try to do insane things like what you are clearly doing and
> must assume you are on your own.
====
        The things that you call insane are normal practice to
computer people.  They assume distributions won't interlock the binaries
to specific versions -- if they NEED to do that, it is known you
either include the lib in a program-private directory, OR you statically
link.

But you don't screw over the user's ability to upgrade their software from
sources as you have done now.

        You seem to have forgotten something, - and that is that
distro's exist to benefit the users -- to make their life easier --
they don't exist to make their own lives easier at user's expense.

That used to be a quick route to losing users -- but given the widespread
cult of apple and walled-gardens, most don't care anymore -- that doesn't
mean it's insane to still want the freedoms that have been on suse for over
10 years.  That suse is changing to releases that users cannot modify seems like
you are moving toward suse as an appliance base -- that can't be modified by
users -- they will just be "users"...

Suse catered to developers at one point as well as well as leaving the door open
for those who use their systems as a server -- or is that crazy too?

Maybe suse is only focusing on the desktop appliance route.

As for reasons why suse has problems with software breakage --- I've been seeing
alot more 'deprecation' and no longer supported messages out of the builds of
products i've done as well as udev messages about unsupported messages in suse's
udev configs.

Perhaps using features beyond their usable life has something to do with
your binary api problems?



       

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Opensuse apps can't be run on newer suse? Why not? Why are they tied to 1 version now?

Cristian Rodríguez-2
El 14/02/13 14:20, Linda Walsh escribió:
if they NEED to do that, it is known you
> either include the lib in a program-private directory, OR you statically
> link.

Ok, to get rid of your illusion, the best way we can do it is by trying
to statically link a simple "hello world" program.

cat getpwnam.c
#include <stdio.h>
#include <sys/types.h>
#include <pwd.h>

int main(void)
{
   struct passwd *p;

if ((p = getpwnam("root")) == NULL)
     perror("getpwnam() error");
   else {
     printf("getpwnam() returned the following info for user root:\n");
     printf("  pw_name  : %s\n",       p->pw_name);
     printf("  pw_uid   : %d\n", (int) p->pw_uid);
     printf("  pw_gid   : %d\n", (int) p->pw_gid);
     printf("  pw_dir   : %s\n",       p->pw_dir);
     printf("  pw_shell : %s\n",       p->pw_shell);
   }
}


This is trivial program, which is ridiculously simple compared to a real
life software.

gcc -static getpwnam.c

/tmp/ccAf3rHn.o:getpwnam.c:function main: warning: Using 'getpwnam' in
statically linked applications requires at runtime the shared libraries
from the glibc version used for linking.

See now that your supposed approach to avoid "lock-in" and to provide
"portability" is doomed ?

Here you have a non-complete or exhaustive list on why suggesting
"static linking" to solve a problem is fooling yourself

http://www.akkadia.org/drepper/no_static_linking.html

Suggesting to use static linking in a distribution or in a production
deployment is absolute madness as that means we must rebuild, re-test,
republish all affected programs when a security problem or bug is found
in a library.

To put an end on this discussion, I must say the problems you are facing
are of your making due to the twisted crazy understanding of how the
system really work or must work.

I rest my case.





--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12