[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Removal of KPackage from the KDEAdmin module
From:       Dario Freddi <drf54321 () gmail ! com>
Date:       2009-12-11 14:45:34
Message-ID: 4e03084c0912110645x45942334o568f9b3200f1957a () mail ! gmail ! com
[Download RAW message or body]

Shaman and KPackageKit are two different tools for two different use cases,
and I possibly see distributions either pick up one or another depending on
what they want to provide. KPackageKit is completely focused on PackageKit
and its philosophy, whereas Shaman has a broader approach also embracing
other backends.

To the bottom: KPackageKit is not a replacement for Shaman and Shaman still
(but probably never will) does not support the tight PackageKit system
integration that KPackageKit does. I see Shaman and KPackageKit sharing some
stuff (icons mostly, I still did not manage to catch up with Daniel these
days), but not much else.

I would have worked on PackageKit only, but talking bluntly PackageKit has
not (yet, and probably will never do since most of them are design
decisions) the potential and the flexibility to be the tool that unites them
all, and its not really wide adoption serves in demonstrating this. In my
view, Shaman has the potential to be a single interface for any packaging
tool (just compare the backend API to packagekit's one and see yourself
why). Yet, if I were lucky enough to have PackageKit working _for real_ on
my system, I'd keep an eye closer on KPackageKit.

And, the two interfaces and workflows are extremely different.

2009/12/11 John Tapsell <johnflux@gmail.com>

> 2009/12/11  <dantti85-dev@yahoo.com.br>:
> > Yup, KPackageKit is almost ready for a review to get in KDE 4.5
> > as my kids have just born I hope I still have time to do my last changes,
> > I'm planning on big revamp on the UI and then start writing the docs
> > (since the UI is changing a bit and writing docs about unstable UI is not
> > cool).
>
> Please work with Dario and try to come up with one solution :-/
>
> John
>

[Attachment #3 (text/html)]

Shaman and KPackageKit are two different tools for two different use cases, and I \
possibly see distributions either pick up one or another depending on what they want \
to provide. KPackageKit is completely focused on PackageKit and its philosophy, \
whereas Shaman has a broader approach also embracing other backends.<div> \
<br></div><div>To the bottom: KPackageKit is not a replacement for Shaman and Shaman \
still (but probably never will) does not support the tight PackageKit system \
integration that KPackageKit does. I see Shaman and KPackageKit sharing some stuff \
(icons mostly, I still did not manage to catch up with Daniel these days), but not \
much else.</div> <div><br></div><div>I would have worked on PackageKit only, but \
talking bluntly PackageKit has not (yet, and probably will never do since most of \
them are design decisions) the potential and the flexibility to be the tool that \
unites them all, and its not really wide adoption serves in demonstrating this. In my \
view, Shaman has the potential to be a single interface for any packaging tool (just \
compare the backend API to packagekit&#39;s one and see yourself why). Yet, if I were \
lucky enough to have PackageKit working _for real_ on my system, I&#39;d keep an eye \
closer on KPackageKit.</div> <div><br></div><div>And, the two interfaces and \
workflows are extremely different.<br><br><div class="gmail_quote">2009/12/11 John \
Tapsell <span dir="ltr">&lt;<a \
href="mailto:johnflux@gmail.com">johnflux@gmail.com</a>&gt;</span><br> <blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex;">2009/12/11  &lt;<a \
href="mailto:dantti85-dev@yahoo.com.br">dantti85-dev@yahoo.com.br</a>&gt;:<br> <div \
class="im">&gt; Yup, KPackageKit is almost ready for a review to get in KDE 4.5<br> \
&gt; as my kids have just born I hope I still have time to do my last changes,<br> \
&gt; I&#39;m planning on big revamp on the UI and then start writing the docs<br> \
&gt; (since the UI is changing a bit and writing docs about unstable UI is not<br> \
&gt; cool).<br> <br>
</div>Please work with Dario and try to come up with one solution :-/<br>
<font color="#888888"><br>
John<br>
</font></blockquote></div><br></div>



[prev in list] [next in list] [prev in thread] [next in thread]