AppStream Ideas and Thoughts

[Matthias Klumpp]

Hi!

On Mon, 14 Feb 2011 16:18:55 -0200, Jos Poortvliet
<jospoortvliet at gmail.com> wrote:
> On 2011-02-13 Matthias wrote:
>> Hi!
>> Wow, this looks very, very cool! I worked on similar issues but with
>> different solutions on my own project (Listaller).
>> Your project would AFAIK be in AppStreams scope and could be a valuable
>> extension for AppStream. I don't think AppStream does something "wrong
>> again".
>> I'll take a closer look at AppTools tomorrow, but from what you said, I
>> guess it would go well with AppStream.
>> Cheers
>>   Matthias
>> 
>> P.S: It's so disappointing seeing all these great ideas come up NOW.
They
>> still existed, but noone thought about joining forces. I developed
>> Listaller, which in a way acts similar to AppTool in some points but is
>> _completely_ different in concept.
>> I never heard of AppTool, which is sad cause from what I read it has
some
>> really great ideas.
> 
> Frankly, I disagree. While solving the rpm-vs-deb-vs-tgz-vs-whatever
issue
> is 
> important, I doubt it'll happen anytime soon - if there WAS a technical 
> solution which also had the 'social features' to win everyone over, we 
> would've seen it by now. And even if it is just not finished yet, I
don't
> see 
> why we should expand the scope of appstream to include an universal
> packaging 
> format. It would just ensure appstream either never finishes or fails.
I really hate speaking of a "package format". I haven't found a term yet
to describe tools like AppTool, Listaller or ZeroInstall, but their main
goal is to make installations/using of 3rd-party software which is not in
the distribution's repos as easy as possible for end users. Most suites
also provide tools for developers to maintain their solutions.

> Apstream has a fairly limited scope: make installation of END USER 
> APPLICATIONS easier and more obvious for end users. And in doing that,
try
> to 
> share as much infrastructure between distro's as is realistically
> possible. So 
> Yes for sharing screenshots, Yes for sharing ratings, but building a new

> packaging format - out of scope.
Neither Listaller nor AppTool want to replace DEB/RPM, it's just an
extension, like Klik was. All these tools interact somehow with the native
package management to fetch dependencies etc. and make 3rd-party apps
usable.
The "unified package format" does not mean Fedora using DEB or Debian
using RPM, it means all distributions sharing one file format to distribute
3rd-party apps, which includes FLOSS projects as well as proprietary
software like Google Earth, World of Goo or Angry Birds. I really hate the
binary installers of Google Earth etc., but if proprietary software
developers publish tarballs containibg statically-linked apps, it is not
really easy for ordinary end-users to get it working properly (and
integrating it into the system cannot be done with dirty, insecure tricks).
Also, ordinary end-users cannot do anything with a tarball containing just
sources they should "compile" to make an application working.

> Appstream with it's GUI's (a Qt and a GTK one) and it's libraries like 
> libattica, packagekit, Xapian etc all aim to use existing distro 
> infrastructure. That's actually the strength of going with packagekit
I contribute to PackageKit as well as developing Listaller - they're
completely different, but make use of each other and interact, to provide
secure 3rd-party software installations. (in theory :D The PK<->LI
connection is not yet finished, and the sandboxing stuff not even started
yet)
Btw: Are there already GUIs in progress? (SC for GTK+, okay. But what is
done with Qt?)

> - I
> bet 
> things like Klik (one-file-applications, yes, has been around on linux
for 
> ages, gents) can be made to work with that too.
Of course! AppTool seems to be an approach in a Klik-like direction too.
(I don't like these solutions much cause of certain issues this concept has
- but the concept I prefer also has weak points, like the need to compile
binary-relocatable applications)

> Sorry for the rant but while I think it's good to discuss ways of better

> managing software on linux (PLEASE do, we haven't been able to solve
that 
> problem for AGES)
YES!!! But only because we never worked together - multiple solutions
raised, no solution was pushed directly by any distributions. Like Vincent
said in his blog post, it's all about getting the right people working
together.
AppStream is IMHO one of the most important projects for the "Linux
ecosystem" we ever had. (And it's so great seeing people from multiple
distributions work closely together)
So, you don't need to excuse, your points are valid :) But I think the
topic of distributing third-party-apps on Linux should be in scope of
AppStream too. (But not be one of it's main goals)

> I think it's bad if such discussions sidetrack us from 
> getting something real done.
As far as I can see, the infrastructure is built step-by-step (otherwise
it would not really make sense :P), the 3rd-party-app distribution stuff
would be the very last step :)

Kind regards
   Matthias

> 
> ;-)
> 
>> On Sun, 13 Feb 2011 17:17:11 +1100, James Rhodes
>> 
>> <jrhodes at redpointsoftware.com.au> wrote:
>> > Hi Everyone,
>> > 
>> > I guess I'm going to be barging in here with my non-standard ideas
and
>> > heretical thoughts.  Over the last 12 months I've been working on and
>> > off a project called AppTools
>> > (http://code.google.com/p/apptools-dist).  It was basically my
attempt
>> > to redesign the way applications are installed on Linux; a project
>> > which I underestimated the time it would take to complete, just a
>> > *little* ;)
>> > 
>> > The goals of this project was essentially to offer a package system
>> > that let you deal with applications in every way you might reasonably
>> > expect to, such as:
>> > 
>> > * Running applications from their packages (done via FUSE, a custom
>> > filesystem and some sandboxing stuff).
>> > * Install applications per user or system-wide.
>> > * Perform the above from a single file (you shouldn't need to
download
>> > a new format depending on what you want to do).
>> > * Reset applications that have been run in their package to the
>> > original package state (resettable filesystem).
>> > * Download applications off the internet without needing to install
>> > repositories, but still automatically get updates for those
>> > applications.
>> > * Do all of this without hiding data away in a database somewhere; it
>> > should all be accessible and readable on the filesystem (each
>> > application should have it's own directory for it's data).
>> > 
>> > There really is a lot more to it than just the list above, especially
>> > in terms of design details.  I suggest you check out the wiki on the
>> > website above if you're interested in the nitty gritty (of which
>> > almost none of it is locked in; suggestions welcome).
>> > 
>> > My concerns with AppStream in it's current format (based on what I've
>> > read on
>> 
>> http://distributions.freedesktop.org/wiki/AppStream/Implementation)
>> 
>> > is that it suffers the same issues as the existing repositories
>> > systems, except that now you have a single repository format for all
>> > systems (which is a step forward none the less).  However, it still
>> > suffers from portability (can I take my packages and give them to
>> > someone else running a completely different distro?), repositories
>> > reliance (can I install and resolve dependencies with the package
>> > belonging to a repository?) and of course it doesn't tackle running
>> > applications from packages (but that might be out of scope for
>> > AppStream).
>> > 
>> > Let me know opinions or thoughts anyone has on AppTools and it's
>> > applicability to the AppStream project.  I think the design
principles
>> > as they stand are similar and that the code base of AppTools could
>> > assist in the project (although checking at "How this will work?"
>> > page, possibly not that much; depends on how you're implementing your
>> > package format).
>> > 
>> > Regards, James Rhodes.
>> > _______________________________________________
>> > Distributions mailing list
>> > Distributions at lists.freedesktop.org
>> > http://lists.freedesktop.org/mailman/listinfo/distributions
>> 
>> _______________________________________________
>> Distributions mailing list
>> Distributions at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/distributions