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:
<summary>Banshee Music Player</summary>
<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
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
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.
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
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
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
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.