On Fri, Dec 19, 2008 at 9:54 AM, Richard Hughes <hughsient@xxxxxxxxx> wrote: > On Thu, 2008-12-18 at 23:18 +0100, Mark wrote: >> On Thu, Dec 18, 2008 at 10:35 PM, Richard Hughes <hughsient@xxxxxxxxx> wrote: >> > You probably need to file a bug about this. I normally add exactarch=1 >> > in my yum.conf file, and I might even argue we should do this my >> > default. >> >> I will fill a bug report about this. (once i find the packagekit bugzilla) > > Default yum policy is a Red Hat bug. > >> >> 3. Oke, mplayer is done installing now and now it asks me to run it.. >> >> why? I really can't think of a valid reason to even ask the user that! >> >> it's pointless! >> > >> > You installed it for a reason, right? Surely if I'm compelled to install >> > a specific application, we should offer to run it? Why make the user >> > navigate the menus and find the correct name and icon? >> >> No, you should not offer it to run. It's unexpected and not asked for behaviour. >> All other distros (that i've used) just install it and are done. They >> don't offer the option to run it. Fedora with packagekit somehow needs >> to act different and that shouldn't happen. Stick to the way other >> distros work and your fine. that's a proven way and works fine. > > *bttzzt* > > Just because PackageKit does things differently to other previous tools > doesn't mean the previous tools were doing things the right way. I'm > actually trying to shift the user away from manually installing packages > in a tool, and start installing them automatically at the point of use > instead. > > See: > http://www.packagekit.org/img/gpk-client-codecs.png > http://www.packagekit.org/img/gpk-client-font.png > http://www.packagekit.org/img/gpk-client-mime-type.png > >> > It didn't just look ugly, it had core architectural problems. PackageKit >> > is a different framework, not an application. >> >> Another reason why it should mature first befora getting included in >> fedora as the default package management system > > If you want a stable rock-solid system please use CentOS or RHEL. If you > want a system that features the latest technologies, use Fedora. > > You can't just develop a new framework by hacking in a dark room for two > years, and then declaring it "finished" and shipping it in a distro. > Architectural changes like this need to evolve, and change as users > needs are discovered. > > Users also have a habit of using the tools differently to what > developers envisage, which always leads to loads of bugs for every new > feature. > > I also think I'm a pretty pro-active maintainer, as the version of > PackageKit in F9 started at 0.1.x and is now at 0.3.11 (which is the > same version as F10 FWIW). File valid bugs and I'll fix them. Sending > mails to a mailing list saying "I don't really like it" doesn't seem > such a useful thing to do. > > Richard. well.. your right on everything. I personally do want the latest features and a little bleeding edge is fine for me as long as it's usable. And.. to be honest.. packagekit fits in those lines. It could also be that it requires some "getting used to" before i like it. On Fri, Dec 19, 2008 at 8:51 AM, Rahul Sundaram <sundaram@xxxxxxxxxxxxxxxxx> wrote: > Mark wrote: > >> >> i did. i can't find the page that says which distro's are using >> packagekit.. >> Do you have a link for me? > > That's a long list. The following (not a comprehensive list) distributions > have contributors working on it. > > Foresight, Fedora, SUSE, Ubuntu, Gentoo, Paldus .. > > I will try and add this information to the packagekit.org FAQ later now that > I have commit access again but the list of backends are already listed on > the site and it should give you a good idea. > > Rahul You clearly don't get the point. Provide a list of distros that use it as there main package management system and split out the fedora derivatives. or sort by "based on: <fedora|ubuntu|etc...>" -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
