Description of problem: fedora should support 1 click install feature to allow easy repository adding (for example without special *-release rpm) and/or package installation. it would make fedora nearer end-user or windows-switcher. example file: http://banshee-project.org/files/banshee/banshee.ymp this file is very easy to understand because of xml tree and the tags. we can of course create own standard or use is in another way. for example url of repo can be url of *-release rpm for repo, which by a option can be erased after installation. this bug shouldn't be left without read. it should be discussed/etc.
The above looks like an unsigned XML file, referring to one (or more?) specific repo. and one or more pieces of software: <repositories> <repository recommended="true"> <name>Banshee</name> <summary>Banshee Music Player</summary> [...] <url>http://download.opensuse.org/repositories/Banshee/openSUSE_10.3/</url> [...] <software> <item> <name>banshee</name> <summary>Banshee Music Player</summary> ...the rpms in the repo. seem to be signed, but with what I don't know, what happens depending on what keys are/aren't installed is an open question or if the repo. has more/less packages than what is specified in the above XML. I'm generally confused about why they are repeating the repodata in the XML file, we have plans to add http repo.conf support to yum, for koji/bodhi integration ... but there is no reason I can think of to repeat the metadata. When that's added to yum, pirut _could_ pick it up if we think that's sane. I'm not sure how the above XML helps with "1-click" installs, we can already do that with a webpage and generic rpm packages (assuming they are signed properly) ... it's just very rarely the right model, because if they can sign rpms with a trustworthy key why don't you have a repo. already and do searches etc. Anything that requires the user to click "I trust this site to allow installing keys/repos" is basically the same as "I trust this site to run arbitrary programs on my machine", and that's not a usability feature. So can you explain better what the above is supposed to help with?
I just wanted to show you existing 1click solution. We're may use our own metadata file/etc ;) . It must just work :> .
You "showed" me the URL ... that doesn't help me understand "how" it works, esp. in the corner cases. What is the usage pattern? Please define "just work".
"just works" - you click an url on some website (maybe even on some fedora's packages website), helper is opened (not by root), it shows info about packages (summary, description), details (repo provided with this meta-file, requires, provides) are hidden. you click "install", second helper is runned (by root), without question repo is added and then package is installed. file I linked here is very easy to understand. http://wklej.org/txt/20b4fd4e2e - version with little summaries
This is not something to really be fixed in yum, though. If we want to implement this in system-install-packages or packagekit, that should be no problem. But yum doesn't technically need to know about it. reassigning to packagekit
<url>http://download.opensuse.org/repositories/Banshee/openSUSE_10.3/</url> PackageKit is never going to let the user add repos like this, it's just way too scary. Also, the trust is _really_ in the wrong place - what if I put the summary as "A way to make your GNOME desktop faster" and install trojan.rpm from www.somescaryhackersite.ru? The summary is basically non-trusted, and of course isn't localised. What use case is this trying to overcome? If it's making it easy to install software already in the repos "click here to install all the files you need to start hacking HAL...", then it's a totally good thing. If it's adding unsigned scary developer repos then I think it's a bad thing. Richard.
Why .ru :> ? Russia is hacker-only country :> ? Check USA :> . 1click is useful when many packages need to be installed * compiz-fusion with all plugins * gstreamer with plugins * gnome Imagine a book example of codecs and drivers installation, when livna is required. You click simple link and livna is being installed as packages from livna too. Some packages do not meet fedora's packaging requirements and author wont submit to livna (quality may be decreased), but sometimes "package requests" are ignored and that packages is the only one.
>Some packages do not meet fedora's packaging requirements If we add a random repo, and the developer commits exploit code, then every system with that repo as enabled can be remote-exploited trivially. It also means if the developer gets bored, and stops providing updates to the repo, then the software does not get security updates, and might block other legitimate security upgrades. Adding repos like this is just not a safe thing to do.
We've discussed this in much detail on the packagekit mailing list recently. The consensus was that this shouldn't be done inside PK, although ONI should problably use PK to do some actions.