Rob Landley wrote:
No, the idea is not to have two versions installed all the time. The idea
is to allow the coexistance temporarily while package manager is upgrading
system.
Isn't this what static linking is for?
If we targeted flashable upgrade, then this would not be needed as
everything would be updated in one go.
Or the package manager would have to be statically linked? (Yeah there's some
implementation details making sure the stuff it calls during its operation
still works, too, changing the $PATH to point to a static busybox covers a
multitude of sins...)
And yes, it's not full solution. Deep library wise dependencies can be
temporarily broken. And yes, we do need stable API for uclibc at some
point. But since we don't have that yet, the temporary install of two
libraries during upgrade is the best option.
Or you could just statically link the package manager?
Yes, static linking would be more bullet proof. But either the user, or
the package manager needs jump through hoops in this case. There needs to
be the static versions compiled, they need to get installed, then finally
replaced with dynamic versions, etc.
As conclusion was previously, it does not make sense to set ABI_VERSION
due to gcc dynamic-linker issues. But it'll help distro which tries to
keep compatibility on packages level (sets the dependencies right and
wants to perform clean upgrades).
*shrug*
I'm not saying everyone needs to use this. I'm not asking support for this.
I'm not even recommending this for anyone.
I only want to do it myself, because it solves my immediate problems
with less work and more user friendly way than static linking. The package
manager is there to handle the other issues.
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
