AppStream Ideas and Thoughts

Mon Feb 14 17:43:36 PST 2011

On 2011-02-14 Matthias wrote:
> Hi!
> 
> On Mon, 14 Feb 2011 16:18:55 -0200, Jos Poortvliet
<snip>
> > 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.

Now I might be mistaken and I know it might be fighting windmills but I 
thought 'we' (= FOSS community) didn't like to make it too easy for users to 
install stuff from outside the safe distro repositories? For security, 
stability and performance reasons? In other words, a cross-distro packaging 
format means - what is the value of distributions, how can we share libraries, 
how do we guarantee security updates in dependencies, stuff like that starts 
biting. Isn't THAT the problem with cross-distro, always-working app 
installers like Klik?

> > 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?)

Even before anyone thought about Appstream, Project Bretzn was started to - 
well, do this and more. Bretzn has a wider scope - yet smaller, mostly more 
practical. They use OBS to build rpms and debs for the major distro's, to 
mention one way they use to cut corners. They worked on OCS, use Libattica etc 
- and with the dude who started it, Frank Karlitschek, being a KDE dude, 
decided to first build a KDE client. They actually also already started a 
library so they could build a GTK client but it was decided by Appstream to 
build on SC so Bretzn dropped that.

Yes, Appstream and Bretzn should work more together, I know. I've been trying 
to get them to work on this ML instead of their own.

> > - 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 :)

Ok, fine if it doesn't slow anything down ;-)

> 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
> 
> _______________________________________________
> 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/8a287153/attachment.pgp>