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 <jrho...@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/distributions _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions