maemo.org - Talk - Development waiting for PR1.2, anyone else?

maemo.org - Talk (https://talk.maemo.org/index.php)

- Development (https://talk.maemo.org/forumdisplay.php?f=13)

- - Development waiting for PR1.2, anyone else? (https://talk.maemo.org/showthread.php?t=50649)

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by Venemo (Post 621151)

Yes, it is a Linux issue, from my point of view.

From my system:

Code:

ii  libdb4.5                                  4.5.20-13.1

ii  libdb4.6                                  4.6.21-16

ii  libdb4.7                                  4.7.25-9

ii  libdb4.8                                  4.8.26-1

It is not a linux problem - it handles multiple versions very well. The problem is with how the packages were prepared.

Quote:

Originally Posted by Venemo (Post 621151)

For example, add the Debian ARM repository, and try to install something from it.
I, for one, wanted to try Mono, so I installed the mono-runtime package.
Apt-get also updated libc6 and libgcc1 during the process.

You're trying to install packages from a different distribution - it will fail. They were not designed to do that - they have dependencies which assume certain environment and if you cannot provide that, you'll have to download dependencies which match.

Quote:

Originally Posted by Venemo (Post 621151)

It would be much easier in terms of compatibility, if it would be possible to have both versions of that library.

Libc updates are hard as it is. There are / were libc compat libraries when it was really needed afair (libc5/libc6), but migrating them between different distributions is suicide.

You're simply trying to do an unsupported thing.

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by Venemo (Post 621151)

Yes, it is a Linux issue, from my point of
view.

It's a distribution issue. Unlike the Microsoft world, where everyone does what MS says, distributions can and do update themselves on their own schedules. Dependencies and packages look internally for resolution, and this is why installing from other distributions is a bad idea. It has nothing to do with -Linux-, and everything to do with the fact that Debian and Maemo are not the same.

This is why Easy Debian exists.

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by Venemo (Post 621151)

It seems however, that the Calendar application is not happy with it, and stopped working properly.
After I downgraded to the previos version of libc6, it worked again.

It would be much easier in terms of compatibility, if it would be possible to have both versions of that library.

On Linux, everything is possible, the only question is how hard it is ;) In your case, I would suggest looking into dpkg --instdir and LD_LIBRARY_PATH, but mixing Debian ARM stuff into Maemo is rough terrain (that's in effect just like copying over things from c:\
windows\system32 between various SPs and editions - sort of works... but more often doesn't :) )

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by attila77 (Post 621198)

About the Windows metaphor:
No, it's more like having 2 versions of the same .dll file, and referencing the right version.

So, I'd like to have the original version which comes from Maemo 5, and I'd like to install the other one for the apps I install from the Debian repo.

Is it possible?

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by Venemo (Post 621433)

Yes, but you'd have to compile from sources and install to your home directory; not the system directory.

The apps that you want to use the different version of libraries you will have to either pass the right flags or environment variable such as the LD_LIBRARY_PATH... or recompile the software yourself using the alternative library path.

You won't be able to point-clicky install software from debian and software from meego and have both software use different versions of libraries... use easy debian for that.

ETA: As for the windows thing, you can't have the same filename in the same directory at the same time regardless of versions. So you'd have to name the dll two different things and the app would have to be written calling that name of dll.

Re: Development waiting for PR1.2, anyone else?

I wanted to learn Qt since before I got an N900, and since I got N900 I want to program for it... since it's all been such a moving target so far, I've not even bothered to begin until PR1.2, qt-creator with madde integration, etc. are released and stabilized. Not that I have any need for this particular setup, but it seems to be the "future best way" so I'll just wait for it to be the present. :)

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by fatalsaint (Post 621446)

You won't be able to point-clicky install software from debian and software from meego and have both software use different versions of libraries... use easy debian for that.

Thanks for your clarification.
I accept that it is not possible, then.

Quote:

Originally Posted by fatalsaint (Post 621446)

ETA: As for the windows thing, you can't have the same filename in the same directory at the same time regardless of versions. So you'd have to name the dll two different things and the app would have to be written calling that name of dll.

The part about filenames is correct, the rest is not.

For traditional COM dlls, you can register multiple versions of them.
The will reside in different physical locations, but an application requesting a specific version of a dll can get it easily.

For the managed programming model:
You can have every version of the .NET framework running alongside each other.
This is also true for your own assemblies, you can have multiple versions of the same assembly in the GAC.

And my point is: it is handled directly by the operating system, the developers don't have to do anything about it.

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by stlpaul (Post 621472)

It is very possible to try out MADDE right now.
I didn't regret it.

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by Venemo (Post 621622)

I was unaware of this as, though I have been a windows administrator for many years - Software Development on windows was never something I got into.

Reading your description I decided too look it up and found:

http://tldp.org/HOWTO/Program-Librar...libraries.html

This part seems to suggest I'm correct:

Quote:

That way, multiple libraries can be on a single system, and the right one is selected for each program. However, if a program breaks on an update to a library that kept the same soname, you can force it to use the older library version by copying the old library back somewhere, renaming the program (say to the old name plus ``.orig''), and then create a small ``wrapper'' script that resets the library to use and calls the real (renamed) program. You could place the old library in its own special area, if you like, though the numbering conventions do permit multiple versions to live in the same directory. The wrapper script could look something like this:

The way libraries are in Linux is you'll usually have libraryname.so.1.2 (version).. and then a symlink from that to libraryname.so - That way the program just calls libraryname.so and you get whatever version is on the system. If you *need* an older version, you can re-link the libraryname.so to the older one and not the newer one to launch the app. But this is ugly.

However, down at the bottom there seems to be a bit of a contradiction:

Quote:

Given this lengthy list, developers of C++ libraries in particular must plan for more than occasional updates that break binary compatibility. Fortunately, on Unix-like systems (including Linux) you can have multiple versions of a library loaded at the same time, so while there is some disk space loss, users can still run ``old'' programs needing old libraries.

Unless it's simply referring to the hack above, I don't know what it means.

Re: Development waiting for PR1.2, anyone else?

Quote:

Originally Posted by fatalsaint (Post 621642)

The way libraries are in Linux is you'll usually have libraryname.so.1.2 < version.. and then a symlink from that to libraryname.so - That way the program just calls libraryname.so and you get whatever version is on the system. If you *need* an older version, you can re-link the libraryname.so to the older one and not the newer one to launch the app. But this is ugly.

It works more like (not that you said it wrong, I just think you might typoed on the first sentence at least):
You install libstuff.so.1.2, and create a libstuff.so -> libstuff.so.1.2 symlink
You build application A on your system. It gets linked to "libstuff.so" which happens to be libstuff.so.1.2, and this latter name is the one the A binary "links with".
You install libstuff.so.1.3, you change the libstuff.so symlink -> libstuff.so.1.3.
You build application B, tries to link with "libstuff.so" which is "libstuff.so.1.3".
You try to run A. It uses libstuff.so.1.2, you still have it installed: no problem.
You try to run B. It uses libstuff.so.1.3: no problem.

This is how it theoretically should work.

But it doesn't matter since here we're talking about Python _and_ Debian packaging mostly.