* Paul Davis <[email protected]> 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: [email protected] mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 ---------------------------------------------------------------------- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme ---------------------------------------------------------------------- _______________________________________________ gtk-devel-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-devel-list
