Re: [Evolution] downloads page

[Alberto Ruiz <aruiz redhat com>]

On Tue, 2013-08-27 at 11:07 -0400, Adam Tauno Williams wrote:
> On Tue, 2013-08-27 at 15:10 +0200, Alberto Ruiz wrote:
> > Is less than ideal, it means a lot of trouble for application
> > developers:
> > a) If you write an app, you have to either learn how to package your app
> > for every distro or convince them to package and maintain the package
> > for you. In practice it means months before your app can hit the users.
> > Compare that to Mac, Windows, Android or iOS, where application
> > developers can go live and distribute their apps in day 1.
>
> This is a downside.  But the same *does* apply to other platforms.  You
> just learn Android packaging as part of Android development; it is no
> less or more documented and opaque.
>
> And depending on you app you may skip in entirely.  I distribute Python
> applications as EGGS.  They install as "pip install {appname}", bam,
> done.  Other categories of apps provide a similar 'round about'.

I am talking about end user applications, not SDKs, frameworks or
services. You are missing my point.

> > b) You can't install parallel versions of your app, for example, if I
> > want a newer version of firefox I have to uninstall the older version.
> > This means that power users have no access to beta versions and
> > therefore _everybody_ hits more bugs on release time.
>
> Most packages are relocatable.  That works pretty well.  But now we've
> jumped from "user" to "power user", which is a bit of a context change.

Not on runtime they aren't. And I don't expect users to learn how to
setup a build environment for things like Evolution or LibreOffice.

> > c) You need to upgrade your whole system to update a single app, to
> > access newer versions of your apps, you need a newer version of your
> > OS... which is a ridiculous requirement if all that you want is to get
> > rid of a bug or access to a new feature in a single app like LibreOffice
> > or evolution.
>
> I upgrade Evolution & LibreOffice all the time - without an OS upgrade.
> This claim is wildly exaggerated.  I am running a very-near-current
> LibreOffice 4.1 ... on openSUSE 12.1.   Installation was as painless as
> a couple clicks.

Good for you, you don't need anything else, you're fine with this, move
along.

A lot of people can't do it in other distros or need to add an extra
repository, which means they put their whole system at risk (it's not
the first time packages from external repos mess up the whole system
package database

LTS/Enterprise/Debian stable are examples of distros where getting stuff
up to date is a painful and needs certain understanding on how the
operating system/package manager works.

> > d) A package is by definition a part of your system, how on earth is
> > making end user apps a part of your operating system an ideal situation?
>
> THEY ARE NOT PART OF THE OPERATING SYSTEM.  That statement is FALSE.
> They are packaged by the distribution, that is all.  DISTRIBUTION != OS.
>
> > RPMs have pre/post remove hooks with root privileges, a broken package
> > can mess up your whole system.
>
> And this differs from installing on other Operating Systems how?  You
> need Administrative access to install all but the most trivial
> applications.  The exception is mobile devices which are a different can
> of worms entirely, and inherit some limitations from that can [speaking
> of having to upgrade the entire OS to access new features...., there is
> no packaging nirvana there.]

In Mac OS X an app is just a folder that you drop somewhere, is the
least intrusive instalation process that I've seen so far. No privileged
actions required. For Android the situation is a little different, a new
user is created for the app to live in a sandbox, which has some nice
benefits. But the main point is that you don't mess with the overall
system. Your app can break as much as it wants, and the package be
rotten and ill formed and your system will still be fine.

> >  This means that every application
> > developer/packager needs to suddenly become a system integrator with all
> > the responsibilities and knowledge that comes with it.
>
> Packagers are indeed System Integrators.

Which means I cannot distribute/deploy my app without knowledge of
system integration for each distro I want to reach.

> > e) This situation actively prevents any closed source app from being a
> > well integrated app in the Linux ecosystem, which is bad for everyone
> > that cares about free software/open source as it restrains the size of
> > our potential user base.
>
> I use several closed source applications.  They provided either packages
> are installers.

Another "Works for me"

You are missing the point, a lot of ISVs are scared away by the
situation, it is not ideal for them, and it is very hard to track
changes on each distro to actually being able to deliver their stuff, so
they end up only supporting Ubuntu or giving up on Linux overall.

> > In any case, if you think that the current situation is ideal for you,
> > then I am happy for you, you're just not the kind of person that suffers
> > from all the issues stated above; but the fact that it does work for you
> > doesn't mean that it is ideal for everybody.
>
> It may not be ideal for all situations, which is not to say that it is
> 'broken'.

You did not address any of the concerns, you either disregarded them
with a "works for me" attitude and you fail to recognize the one problem
here: only open source enthusiasts or big enough corporations are up to
the task of coping with the cost of developing and distributing an
application for Linux distros, for each app you need an army of 3/4
people to take care of the app on each distribution. And you need to
keep constant care and testing to make sure they all run in the
different versions.

This is bad for Linux, and this is bad for open source.

The application developer suddenly has to cope with this issues that
should not matter at all to him:
- Fragmentation (multiple distributions)
- System integration (I just want to write an app!)
- Parallel installable versions.
- Infinite testing matrix.

But then again, until we get the application sandboxing tools in place,
this whole discussion is a waste of time.

-- 
Cheers,
Alberto Ruiz