[kubuntu-devel] Muon Discover

[Aleix Pol]

On Wed, Jan 8, 2014 at 4:20 PM, Harald Sitter <apachelogger at ubuntu.com>wrote:

> On Wed, Jan 8, 2014 at 2:42 PM, Aleix Pol <aleixpol at kde.org> wrote:
> > On Wed, Jan 8, 2014 at 1:03 PM, Jonathan Riddell <jr at jriddell.org>
> wrote:
> >>
> >> On Tue, Jan 07, 2014 at 02:25:27PM -0800, Scarlett Clark wrote:
> >> >    Is this the default package manager? Or Muon?
> >> >
> >> >    I need all ways to bring this up eg.. command line. I have so far
> in
> >> > a
> >> >    search from KickOff and KickOff->Programs->Muon Discover
> >>
> >> We have both Muon and Muon Discover installed by default.  Arguably this
> >> is application duplication and very un-ubuntu.
> >>
> >> Does anyone have an opinion of whether Muon Discover is mature enough to
> >> stand along and for Muon to be removed from the images?
> >>
> >> You can access it by KickOff -> Computer -> Software Centre too which
> I'd
> >> expect to be the primary method.
> >>
> >> Jonathan
> >>
> >> --
> >> kubuntu-devel mailing list
> >> kubuntu-devel at lists.ubuntu.com
> >> Modify settings or unsubscribe at:
> >> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
> >
> >
> > I would say that the decision is not really about maturity but about user
> > target. I don't think an end-user should understand all the semantics
> that
> > Muon Package Manager exposes. If a user has the knowledge to use Muon PM
> he
> > has the knowledge to install it from Discover or even apt-get.
>
> Indeed. The argument never was that software center or discover
> weren't mature enough, but that they do not deal in packages. They
> deal in applications (read: in things that have a desktop file). So if
> you want or need to install a package (say 'bzip2') you won't be able
> to do that with discover because of the way it is designed.
>
> Personally I always found this argument silly because it implies that
> a user knows the difference between Muon and Muon Discover and will
> choose the correct tool for the job at hand <- so very very very
> unlikely...
>
> Really there are three groups of people we have to consider:
> a) the user who only wants to installation an application and will not
> ever want to install a package (by himself, support cases excluded
> becasue those usually will offer concrete apt-get commands anyway)
> b) the user who perhaps could be called a sysadmin and wants to
> explicitly manage packages, but likes to do it in a GUI
> c) the user who likes direct control but feels that a GUI slows him down
>
> And here is the thing.
> A user of group a) won't be able to graps the concept of either b) or
> c) and have a very hard time trying to manage 'apps'.
> A user of group b) will be able to deal with the usage paradigm of a)
> but might not be able to do what c) does.
> A user of group c) will be able to do manage 'apps' and 'packages' given a
> gui.
>
> Looking at the presented use cases there is no reason why muon (the
> package manager) needs to be part of the default install. You could
> technically even remove apt-get itself. Because b) will be able to use
> muon-discover to install muon and c) will be able to use muon-discover
> to install muon to install apt-get. Of course latter is not very
> convenient so one can make an argument for keeping apt-get regardless
> (plus I doubt you could remove it anyway ;))
>
> Long story short: if someone wants a gui package manger, they can
> manually install muon via discover or apt-get, absolutely no reason
> why we'd need it in the default install.
>
> HS
>
> --
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>

FWIW, bzip should probably be installable from Discover, since it's an
end-user application.
What the user won't be able to find in discover is libbz2. Arguably, -dev
packages should be available in discover as well.

Aleix
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20140108/87939a3d/attachment-0001.html>