AppStream Ideas and Thoughts

Tue Feb 15 08:16:07 PST 2011

On Tue, 15 Feb 2011 09:04:43 +0100, 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.
True.

> 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].
I'm aware of this, I know how package management systems work and why they
handle things like they do today. It is very hard to find a model suitable
enough for every vendor, that's why discussion is needed.
I don't want to list how "my tool" handles the stuff (trusted software,
dependencies, etc.) because this might become very off-topic.

> They 
> especially fail to understand the the main problems are not technical 
> (although there are several pretty hard technical problems) but 
> organizational.
Organizational problems can be solved as well as technical problems :)

>> 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.
Okay, let me explain this: When I started the Listaller project, I did not
want to make a "software installer" at first, I wanted to create a
"software manager" - the same as the Ubuntu Software Center is today, a
tool displaying applications to the user, not packages.
I wanted to have ALL applications installed on the system in scope, so I
included an abstraction layer to handle LOKI, Autopackage, Mojo,
ZeroInstall, Klik etc. Then I started to develop an own cross-distro
software installer, cause I strongly disliked the binary installers we
still have for proprietary stuff.
I created something similar to Enricos "distromatch", added a security
concept and implemented an easy way to handle updates for an application.
This was an experiment too.
Then I started to address every single issue distributors, users and
developers had with Listaller, to make the solution work or everyone. (a
big, big mistake in retrospection)
I don't say "I have the solution", we should better create one solution.
Then nobody will start doing duplicate work again :P (And I have absolutely
no problem to drop my code in favor of new, unified specs how to handle
this stuff)

Giving users (or admins) the opportunity to install software without being
dependent on the disto repositories, is also a big increase of individual
freedom. Which first sounds strange, cause I can do everything with my
Linux machine, becomes obivious if you look at the use-cases for PackageKit
[1]: They don't have the knowledge to compile <new_game> or
<new_firefox_version> by themself, so they need to rely on the
repositiories, which only offers a few tools.
Also, an unified software distribution format would make it possible to
distribute one file for all distributions. This would stop the fact, that
most Linux software is only precompiled for Ubuntu at time, and other
distributions don't get fresh binaries.

Of course, the whole process needs to be secure, mabe only admins should
be able to install (signed) software. And developers should get a tool like
"lintian" or "rpmlint" to create sane software pkgs. Libraries should be
out of scope for an approach like this.

Cheers,
  Matthias

P.S: Sorry for the off-topic... @AppTools dev: I looked at you concept: Is
the documented stuff working at time? I branched your repo, but I only get
a win32 dir with vcproj files... Is this the right (Linux) project? (Send
me a mail to not fill this list with probably AppStream unrelated stuff)

> 
> Florian
> 
> [1] https://fedoraproject.org/wiki/User:Ffesti/PackageHandling
> [2] No, I won't list them here. It is your job to come up with arguments

> for your project.
> _______________________________________________
> Distributions mailing list
> Distributions at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/distributions