Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
- From: Alberto Ruiz <aruiz gnome org>
- To: David Zeuthen <zeuthen gmail com>
- Cc: "gtk-devel-list gnome org" <gtk-devel-list gnome org>, Alexander Larsson <alexl redhat com>
- Subject: Re: Resource framework, relocatability (was Re: Glib: a Win32 discussion)
- Date: Mon, 18 Apr 2011 18:41:58 +0100
2011/4/17 David Zeuthen <zeuthen gmail com>:
> Honestly, I'm not that interested in solving the "make relocatable app
> providing plug-ins work without installing the app" use-case work
> outside Linux.
>
> FWIW, even on Linux, I'm not even sure it's something worth worry
> about - for the few cases where you need this (such as when installing
> a MP3 or H264 decoder (e.g. a GStreamer plug-in)), it's fine just
> using the platform mechanism (e.g. RPM or DEB).
David,
I'm afraid it's not just fine for several reasons:
1. If you want to make your app widely available to different
distributions, you need to learn how to create your package for each
one of them (and each distro has its own level of difficulty when it
comes to create a good package). This makes the "getting your apps to
the users" story really BAD for GNOME. You can get an app up and
running in Android and OSX in one or two days if it is really simple,
hitting the appstores is a matter of barely a week. Getting to the
users on Linux can take months.
2. A badly written package can break your package databse in the long
run, (there's plenty of stories like this in the context of PPAs in
Ubuntu), or mess up with your dependencies in critical ways that the
user won't be able to solve. Relying on the system packaging to deploy
apps is just broken. Adobe AIR in Ubuntu has broken my system a few
times while messing with apps. Creating well formed packages and
maintaining them is less obvious thatn you think.
3. You may need your own version of several platform libraries (such
as Gtk+). Or ship your own and not having to worry of those being
provided by the distro. Again, this story is pretty BAD when you try
to do things this way. You may give examples of success in this
approach by Google or Dropbox where things are mostly okay. But that's
because they do a really good job.
I don't want to rely my system integrity on the ability of all
application developers to do a really good job on .DEB/.RPM/...
packaging.
So yeah, .RPM/.DEB is absolutely fine for system level components
(platform, shell...). But for applications, I have to say I really
don't agree at all that it is the right mechanism, unless you come up
with a sandboxed approach for apps installed by the user.
--
Un saludo,
Alberto Ruiz
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]