Muon and kde-gtk-config moved to kde/workspace - was - Re: Moving repositories in the module structure

Aleix Pol aleixpol at kde.org
Thu Nov 13 15:03:00 GMT 2014


On Thu, Nov 13, 2014 at 3:50 PM, Albert Astals Cid <aacid at kde.org> wrote:

> Aleix, can you please explain to us why Mion Discover and Apper are two
> different things in principle?
>
> Seems the Apper guys disagree.
>
> Cheers,
>   Albert
>
> El Dilluns, 6 d'octubre de 2014, a les 22:46:49, Matthias Klumpp va
> escriure:
> > 2014-10-06 19:57 GMT+02:00 Albert Astals Cid <aacid at kde.org>:
> > > El Dilluns, 6 d'octubre de 2014, a les 01:30:47, Aleix Pol va escriure:
> > >> [...]
> > >> I don't expect to compete with Apper. Muon Discover is a software
> center
> > >> and that's the main solution I'm pushing here, as I explained in
> Plasma.
> > >> Apper is a package manager. That is, a way where we can display to our
> > >> end-users what software there's available and also lets us a couple of
> > >> tricks to get biased.
> >
> > I (as Apper contributor) would disagree with that - Daniel renamed
> > KPackageKit to Apper years ago to stress that Apper is not about
> > packages, but especially about applications. Unlike Muon or GNOME
> > Software, the goal for Apper is to manage packages and apps in one UI
> > though - and of course, Apper provides the session interface for
> > PackageKit, which Muon does not (yet?).
> > Does Muon work well with PackageKit on !Debian-based distros? I had
> > lots of trouble with porting the Ubuntu Software Center to PK, since
> > PK uses a completely different paradigm and API, compared to the
> > Aptdaemon interface the USC used, so it would have required a complete
> > rewrite.
> > Last time I looked at QApt, it looked slightly more similar to Aptd
> > compared to the PK API.
> > (I'll soon test Muon on Fedora by myself, but more from an "what can
> > be improved in AppStream?" PoV)
> >
> > >> I think this is very important, because it opens an opportunity to
> offer
> > >> the end-user the full KDE experience we've been talking about. So far,
> > >> the
> > >> way everyone had to expose software was by creating a (usually
> spin-off)
> > >> distribution where there was tons of software pre-installed. By
> providing
> > >> a
> > >> software center we open channels to communicate with the user where he
> > >> can
> > >> leverage on previous' users experience, as well as our own.
> > >
> > > I'm not sure I understand the difference between a "Software Center"
> and a
> > > "Package Manager", can you elaborate what is the difference?
> >
> > Software Center almost always means that it shows GUI apps instead of
> > packages, where "app" is more tightly defined as "stuff which ship a
> > .desktop file in share/applictions with Type=application".
> > Package Managers display all kinds of packages on the system,
> > including debug symbol packages and e.g. header packages.
> > The Software Centers are generally thought to be more end-user
> > friendly, while package managers have a technically advanced user as
> > target audience.
> > Cheers,
> >     Matthias
>
>
There's 2 main differences:
1. Muon Discover has historically used OS metadata to define what are
applications an what's relevant to the users (AKA end-user applications).
Although they claim it will be done eventually on Apper as well. In any
case Muon Discover doesn't aim to manage packages, it aims to provide a
library of resources for the user to enhance his KDE/Plasma experience.
2. Muon has different backends, so we're not solely relying on PackageKit
which means it can act as a frontend to different technologies other than
packagekit, currently bodega, KNS/OCS and Apt (the last one for historic
and practical reasons).

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141113/ee231f40/attachment.htm>


More information about the kde-core-devel mailing list