AppStream Ideas and Thoughts

[James Rhodes]

On Tue, Feb 15, 2011 at 7:04 PM, FlorianFesti <ffesti at redhat.com> wrote:
> Hi!
>
> Let me start with a preliminary remark:
>
> Your perception that your package format (or what ever you call it) is
> relevant within AppStream is wrong. It is wrong because it is in another
> layer of the package handling stack. I am currently working on a document
> describing the layers [1] but it is not ready yet. But the pure fact that
> you could add the AppStream features on top of a repository with your
> packages should make that clear. AppStream is not about package formats.
> Packages are taken for granted. We don't mind where they come from, what
> they contain or how they are installed. These are all questions of the layer
> below. While our group might look like the right people to talk to they are
> not. Especially not here in the context of AppStream.
>
> On 02/15/2011 12:52 AM, James Rhodes wrote:
>>
>> I believe that the reason these projects generally fail is because
>> there is no adoption by the mainstream distributions, usually, at
>> least from the projects that I've previously seen, because they don't
>> integrate with the underlying package system, or they provide an
>> inconsistent experience (like you can run an application from a Klik
>> package, but if you want to install it you need to go find a DEB /
>> RPM).  AppTools is designed such that it integrates with the
>> underlying package system where possible, and provide a consistent
>> user experience.
>
> I believe that the reason these projects generally fail is because they fail
> to understand why distributions work the way they do and fail to find
> arguments why this reasons don't apply to their model[2]. They especially
> fail to understand the the main problems are not technical (although there
> are several pretty hard technical problems) but organizational.

I know why package managers work the way they do; having everything in
a central repository at first seems to be a great way to ensure that
every software that the distribution wants to offer has the
dependencies available for it, which for well-known open source
software is fine.  There's a high change that users will be able to
find the software they want in the repository.

It falls apart when a third-party wants to offer a package without
setting up a repository for each and every distribution they want to
target, whether it be open source or closed source (of course the
former can offer a tarball; the latter can not).  Setting up a
repository for every distribution is beyond time consuming, and let's
face it, third-parties just don't do that.

So you end up with these .bin or .run binary files that they ship and
there's no way for a user to tell what this installer file is going to
do or where it's going to place files.  Maybe it's just me, but I
don't like running "installer" applications as root when I can't find
out what they're going to do.  But the current package management
system gives neither users or developers a choice here.

Finally, don't forget that there's no way to uninstall the application
(I've never seen an uninstallation binary provided), and so when you
run these ugly installation hacks, you have to be sure that you
*really* want this software on your system because there's no way to
cleanly get it off.

So yeah, I understand why distributions package software like they do.
 It's just that their package management systems don't work outside
the "walled garden" they set up (from a usability endpoint of course).

>> But while you'll have a consistent interface, you won't have a
>> consistent software selection.  We already know that different
>> distributions name packages differently (that's why AppTools has a
>> standardized package naming specification so that it's not an issue).
>
> This shows very well why you fail: "Everybody is different. But I have the
> solution: I am different, too." Why don't you just suggest to abandon all
> distributions except one.

I appear to have not written a wiki article on this, but the naming
standards apply to AppFS packages only.  For compatibility with
existing systems, a central package mapping service called DepResolve
will exist that maps the dependencies listed in a package with the
actual package that needs to be installed based on the current
distribution.

Regards, James.