Applications and bundled libraries

Posted Mar 18, 2010 3:26 UTC (Thu) by blitzkrieg3 (guest, #57873)
In reply to: Applications and bundled libraries by Frej
Parent article: Applications and bundled libraries

> The big advantage is app developer control. Imagine being able to update
> your customers/users napplication without being dependent on N different
> distributions somewhat random selection of software, it also avoids "Oh to > get our next update, you need to update your distro" which is
> completely unacceptible from an administration point of view.

First of all, this is the job of the system packager, not the app dev. Second of all, major distros have package dependencies with automatic resolution these days. I know on my system it is 'yum update firefox'. Why is it better to have a dedicated application installer pulling in /usr/local/lib/libpng.so and having the dependency resolver pull in an update to libpng?

to post comments

Applications and bundled libraries

Posted Mar 18, 2010 8:07 UTC (Thu) by Frej (guest, #4165) [Link] (9 responses)

>First of all, this is the job of the system packager, not the app dev. Second of all, major
distros
>have package dependencies with automatic resolution these days. I know on my system it is
>'yum update firefox'. Why is it better to have a dedicated application installer pulling in
>/usr/local/lib/libpng.so and having the dependency resolver pull in an update to libpng?

Why do we even have a system packager?
It's a source of contention, say you just released important update 1.4.0, but no users can get
it!
And you have no control of when they get it. It may even be they never get it, because the
distro
think it's too big a change.

Every software must be packaged N times for N distros, and the system packager will always
say "NO!" to any 1.2->2.0 update for a stable dist. Even if the developer want it and some of
the users wan't it.

For a (private) laptop user and the app developer it's a mess. The the distro in complete
control
of your laptop, but nobody really needs that. But the the current complete control/handling of
your system is only great for admins who wan't to control a multiuser system or a webserver.

The point of a self-controlled application is being able to update the actual app, not libpng.
Who
cares about libpng. And it's better because the app developers is in control of their own app
and in direct contact with it's users.

PS: Anything that requires the terminal is not a real solution for 95% of the world ;)

Applications and bundled libraries

Posted Mar 18, 2010 11:53 UTC (Thu) by tzafrir (subscriber, #11501) [Link] (1 responses)

Because otherwise the developer will need to test N! combinations of interacting versions.

Applications and bundled libraries

Posted Mar 18, 2010 20:14 UTC (Thu) by Frej (guest, #4165) [Link]

Exactly and (M-K)! for K libraries that are bundled ;).
Note that the app developer can choose which the subset K to bundle so the remaining part, M-
K are those such that they are less likely to cause problems.

But the point is that the app developer can fix the error (including version incompatabilities) and
push an update, fixing any problems without the middle-layer of a distro.

I'm not saying this is the best solution for everybody!

Applications and bundled libraries

Posted Mar 18, 2010 16:51 UTC (Thu) by viro (subscriber, #7872) [Link] (1 responses)

And when somebody finds an overflow in aforementioned libpng, they are supposed to try and catch every duhveloper that happens to use said library, explain to each why multiplication overflow is a bad thing (starting with "what's multiplication?" in a lot of cases), then convince them to update their stuff, then upgrade every such crapplication on every box out there.
Including laptops. _Wonderful_.

Applications and bundled libraries

Posted Mar 18, 2010 20:34 UTC (Thu) by Frej (guest, #4165) [Link]

Sure under the assumption of a crapplication and duhveloper the implication is that bad things
happen. But i don't agree the assumption is always true ;).

It a question of trust, why force the user to only trust the distro? Sure other models have the
problem you state - but why can't we build a system where it doesn't happen? just because
applications bundle stuff, they can still hook in to the same updater the admin/user runs.

A distro letting go of control does not mean that the that sysadmin has less control/more work..
We can do both, it's just harder and new territory.

Applications and bundled libraries

Posted Mar 18, 2010 19:02 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (3 responses)

You are picking the wrong distro, methinks. If you want the absolute latest source from the developer's keyboard, grab something like Gentoo or Arch. If you want to run something tested to death and guaranteed stable, pick some Enterprise distribution.

As a end user (and sometime sysadmin, and developer at times) I don't want some random developer dictating what version of their package I should run. I'm happy to run the development snapshots of some stuff at my own risk for non-critical use, but only thoroughly wetted and QA'd software on a enterprise distribution for real-world uses.

Sometimes I might decide that what the distro ships is too outdated, and (carefully counting in the extra cost of keeping track of upstream myself) replace selected packages with newer versions. But never across the board.

Applications and bundled libraries

Posted Mar 18, 2010 20:45 UTC (Thu) by Frej (guest, #4165) [Link] (2 responses)

Good questions, but ideally choice of distro shouldn't matter.

>You are picking the wrong distro, methinks. If you want the absolute latest source from the
>developer's keyboard, grab something like Gentoo or Arch. If you want to run something
>tested to death and guaranteed stable, pick some Enterprise distribution.
What if i want stable distro/system but with newest app a,b and c? And developer of a b or c
doesn't want to support N distros? They can just bundle the libs they need.

>As a end user (and sometime sysadmin, and developer at times) I don't want some random
>developer dictating what version of their package I should run. I'm happy to run the
>development snapshots of some stuff at my own risk for non-critical use, but only thoroughly
>wetted and QA'd software on a enterprise distribution for real-world uses.

I'm sure a sensible system would allow a user to refuse appliation updates.

>Sometimes I might decide that what the distro ships is too outdated, and (carefully counting
>in the extra cost of keeping track of upstream myself) replace selected packages with newer
>versions. But never across the board.

Nobody can argue with that, but the app developer still has to wait/hope for N
distros/packagers.

Applications and bundled libraries

Posted Mar 19, 2010 18:16 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (1 responses)

I'm sorry, but "stable distro" and "latest versions of A, B, C" just don't jibe.

Whenever I really needed installing non-official software like that, after much looking around I usually decided not to do it. And when I did, the "application A" for which I truly, really, no-other-option-works, had to get a later version it was something very localized (not exactly (pieces off) newest Gnome or KDE), and I installed that from source (and created a package for simple installation/update). The "dependency hell problems" mentioned mostly just weren't.

Where I did install a larger set of stuff was when we had Suns with Solaris, where many pieces were almost useless (like the infamous cc or its klunky sh, or its bloated beyond recognition version of X) . There the first step was what somebody called GNU > /usr/local (which did include X Windows, TeX and an assortment of other pieces). But it was still done carefully and as limited as reasonable.

Applications and bundled libraries

Posted Mar 21, 2010 0:13 UTC (Sun) by nye (subscriber, #51576) [Link]

>I'm sorry, but "stable distro" and "latest versions of A, B, C" just don't jibe.

That is because in your mindset every application is inextricably part of The System. That isn't the way anyone thinks outside of the Linux ecosystem, and it's frustratingly difficult for one side to understand the other.

The average user wants to continue with the same stable system (with the appropriate fixes if they're towards the higher end of the average), but with the option of whatever software versions they choose. A Windows user doesn't expect that updating Firefox may require them to reinstall every other application on their system to support a complex web of interdependencies - the idea would be beyond ludicrous. This highly desirable goal is currently achieved by bundling libraries - perhaps it always will be.

It doesn't have to be that way, but the [overly IMO] rapid pace of Linux distribution releases means that having separate system and applications package trees would rapidly lead to massive combinatorial explosion.

Applications and bundled libraries

Posted Mar 19, 2010 20:58 UTC (Fri) by dirtyepic (guest, #30178) [Link]

> Why do we even have a system packager?

You've answered your own question. Because every app developer thinks their app is so important that users need to be using the latest version the day it's released, with no thought to system stability or security. Who cares about libpng indeed.