Re: Glib resource framework

[Enrico Weigelt <weigelt metux de>]

* Paul Davis <paul linuxaudiosystems com> schrieb:

> > What is the problem that should be solved by that ?
> 
> because this is the 21st century in which (1) applications consist of
> more than a binary executable 

I dont see a problem in this point. Actualy I'd prefer using
even more separate binaries (and processes) for lots of
architectural reasons.

> (2) users like easy-to-install-and-remove programs

This is what distros and their packages are for. All the distros
have their different use cases and audiencences and therefore
valid reasons for their different approaches.
(eg. Gentoo is not so different from Debian, just because they
can, but because of the completely different scope)

> (3) ISV's like ways to provide users with
> easy-to-install-and-remove-programs

That's what the distros's packaging toolchains are for.
If upstream does a good job (clean architecture and codebase),
the actually packaging efforts are quite minimal.

> (4) ISV's need to know that the versions of the library they
> are linked against is the correct one

Proper dependencies and maybe additional checks in the
configure stage (assuming that's *really* necessary) handle this.

> (5) applications written using C++ have a whole additional
> set of problems, which i will not detail here

Well, I'm really interested in hearing them in detail.

> (6) some ISVs do not
> want their software to be primarily distributed by dozens of
> per-distro packagers.

Simply install your bundled apps into some clearly specificed
prefix (eg. /opt/<my-app-name>)

> The splintering of linux into dozens of different distros, all with
> their own particular foibles, means that its much easier to approach
> things from a "bundle" perspective.

Not really. Perhaps on a quick look, but not in long terms.
With those bundles you take the burden of many things that
are normally the job of the distros. In the longer run, it
just moves the problem, not solving it, and you'll also
have to maintain all the bundled 3rdparty-packages.
(I've seen a lot of projects where exactly this caused big
problems, which just happened to become visible with a 
few years delay, but then became really ugly)


Please be careful when comparing with the MacOs world - they
have a really carefully engineered homogenous environment
(which also imposes several constraints on the whole system
architecture to make this all work), designed top-down.
Completely different situation from the GNU world.


All of this we're talking about right now are build and
depolyment issues. Trying to solve them in an helper
library like glib or gtk is fighting in the wrong place.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt metux de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------