AppStream Ideas and Thoughts

[Jos Poortvliet]

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.

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.

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 bet 
things like Klik (one-file-applications, yes, has been around on linux for 
ages, gents) can be made to work with that too.

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) I think it's bad if such discussions sidetrack us from 
getting something real done.

;-)

> 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.freedesktop.org/archives/distributions/attachments/20110214/82c951ee/attachment.pgp>