Hi! On Mon, 14 Feb 2011 16:18:55 -0200, Jos Poortvliet <jospoortvl...@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 >> >> <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 _______________________________________________ Distributions mailing list Distributions@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/distributions
