On Thu, Dec 18, 2008 at 10:17 PM, Jeff Spaleta <jspaleta@xxxxxxxxx> wrote: > On Thu, Dec 18, 2008 at 11:40 AM, Mark <markg85@xxxxxxxxx> wrote: >> 1. While i was searching for my packages to install (in this case >> mplayer) i was looking at the bold font. My first idea that that was >> the name of the package but no someone somewhere decided to make the >> short package description in BOLD and first.. making it hard to find >> the package name itself because that's just not there (the rpm name >> is! but the package name that is defined in the rpm spec file is >> nowhere to be found. I think that should be written in bold then the >> description below it and the rpm name + architecture should not even >> be there > > The decision to highlight the bolded information has been an upstream > design choice, and its been a subject of debate even among fedora > developers in the past. It's upstream's design choice, and upstream > means for it to be consistent across distributions. To get it changed > you'll have to get upstream to change it, and that may require a > cross-distribution consensus discussion. I don't know if i'm gonna put that effort in it. I don't like packagekit that much > > I'm not sure what you are refering to by "packagename" > I see the packagename-version-release.arch just underneath the bolded > summary text in my mplayer search listings at the moment. The > packagename is encoded in the rpm name is it not? It's in the spec file defined as "Name: <<the name>>" > > >> 2. WTF All my packages are double... which ones do i need? > That I don't currently see happening on my x86 system. Is yours a > 64bit system? Do you see a 32bit AND a 64bit version for each package? > If so, those are not technically duplicates. I do a search for > mplayer on my 32bit F10 system and I get only one listing per item, no > duplicates. Now maybe the UI for multiarch situations isn't optimal, > but if it isn't its a discussion for upstream development. I see 2 identical names and descriptions just a different architecture > >> 3. Oke, mplayer is done installing now and now it asks me to run it..why? > > Another upstream design decision. This is functionality that shows up > with applications which appear in the menus and have .desktop files. > installing mplayer did not do this. installing gnome-mplayer did. I > don't see an obvious way to turn this off. > I see a way: delete the code that does it ^_- Without the fooling. there should be just a conf setting for this to enable/disable it >> 4. Another (minor) thing. > This may not be PackageKit's fault directly, but maybe a problem with > the default authorization policy provided managed by PolicyKit. > > If you open up the Authorizations gui. System->Administration->Authorizations > And look under the packagekit actions which have authorizations > associated with them: > org.freedesktop.packagekit.system-trust-signing-key I don't have anything called: "Authorizations" in the System->Administration menu. > > This action controls when a key is to be imported into the rpm > keyring. By default is configured to require admin authorization each > time. It could be changed to automatically allow console user to do it > without a authorization check. is that default the wrong default? I > don't know. If its the wrong policy for you personally, that's easily > editted in the Authorizations gui. I don't know if that's wrong or right but asking for the root password twice in one install instruction is overkill. Just asking if it's oke to add the key is one thing but asking that and asking the password seems wrong to me. It just should not (in my opinion) ask for the same password again when i gave it a few seconds before that > > Let me stress this. PackageKit is asking PolicyKit for action > authentication. PackageKit is not deciding to ask you for a password. > PolicyKit is. PolicyKit has default policies in place for a number of > actions. Those policies can be edited to change the behaviour if the > default isn't to your liking. > > Yes the PolicyKit idea is sort of new so it might take a little > getting use to. But once you get it, its quite flexible in allowing > you to define an authorization policy that makes sense for you. Maybe > you just want to authorize as the sysadmin once per session for all > actions..you can do that. Maybe you just want the active console user > to be authorized without a password for any PolicyKit controlled > action... you can do that too. Maybe you want to grant or deny > specific users access to specific actions regardless if they are at > the console or not... you can do that too. I don't want nor need that kind of power. (nice to have though) the default policies should just be right in a released "stable" product (fedora 10) if they aren't then it's beta/rc and doesn't belong here, yet, but belongs in rawhide. The default policy should be that during the installation thap part is working in root otherwise it can't install a thing. So it simply can add that gpg key if it wants to (glad it's not AI). It should just ask me if i want to add that key, no problem, but since it's already working in root stuff, again because it's installing! i'm just logged in as a normal non-root user, to should not ask for the same password again. Asking for it again is just pointless i think. > > -jef Mark > > -- > fedora-list mailing list > fedora-list@xxxxxxxxxx > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list > Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines > -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
