AppStream Ideas and Thoughts

[Matthias Klumpp]

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.

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