Dear List, I need some feedback on the feasibility of the proposal below from this list.
ADDING ONE CLICK INSTALL SUPPORT TO FEDORA (Package-Kit in effect)
To install a package x in Fedora one has to add the repository via the command line (or gui) and then type "yum install x" to get the package installed. In the one-click-install feature we have an xml file per-package which contains information in it such as package name,version,repository links (for installing further dependencies), GPG key etc. One may upload these xml files on the web and an user may click on these xml files in a browser. Once downloaded the a parser parses the contents of the file and automatically adds the requisite repositories and downloads requisite packages for dependency preservation.
I have been discussing this topic simultaneously on 2 lists because of the nature of the problem. Here are the 2 threads:
[1] http://lists.freedesktop.org/archives/packagekit/2009-March/004569.html
[2] http://groups.google.com/group/redhat-summer/browse_thread/thread/50de9e16d5...
I think its time to summarise my proposal. The way I see it, there are 4 things to do:
1) Add .oci support to package-kit. 2) Add pluggable policies 3) Add voting system to package manager 4) A server that receives these votes and maintains a list of repos in sorted order. The distro maintains this. Leave it to the user which repo he wants to add now.
Explanation: 1)Add .oci support to package-kit: This involves adding C code to Package-Kit. Much of the work has been done by Dorian Perkins and is available at http://www.cs.ucr.edu/~dperkins/projects/pk-oci/.
2)Pluggable Policies: The policy of what to allow to install will not be agreed
across all distributions. So instead of discussing a policy that will never get unanimous
approval the install policy pluggable, and allowing the distribution to choose the policy may be better. Some example policies would be
* Only allow packages in the distribution itself * Only allow packages that are whitelisted or in whitelisted repository * Allow installation of anything that is not on a blacklist * Allow installation of anything"
(In words of Benji Webber)
3) Add voting system to Package Manager: The word trust has to mean something that the end user understands, as opposed to GPG keys. One way of defining trust is by votes. It is my proposal that we enable a voting system at the package manager end so that every time a repository is added and a package installed for the first time users are asked for a "Recommend" vs "Do not recommend" vote. Conversely, every time a user disables/removes a repository he is asked whether he votes "Do not recommend". These votes go to a centrallised server
I was advised on the Fedora list by Patrick Barnes to use the voting approach. I thought it made sense since it will keep evil people (repositories) away the same way wikipedia protects itself from evil people. Also there may be admins, like me, who shall ban a particular repository from the listings if it is found to be a malicious repository. If a repo is evil, there *will* be several "do not recommend" votes to it too which will attract attention.
4) A server that receives votes and maintains a listing of repositories in sorted order: We could make modifications to https://admin.fedoraproject.org/pkgdb so that it provides one-click-install links to all packages thus. Similar efforts are at:
[1] http://www.apturl.net/ [2] http://packages.opensuse-community.org/ [3] http://www.allmyapps.com/
I can set up a prototype server which accepts these votes and displays reposiories/packages accordingly. Once I have successfully built all the things I have mentioned, I dont mind buying hosting space to host it as a proof of concept.
On Wed, Apr 1, 2009 at 1:38 PM, Debayan Banerjee debayanin@gmail.com wrote:
- Add pluggable policies
Pluggable policies are a political landmine in terms of coordinating with 3rd party repos. Should the Fedora Project be setting policies with regard to how users use 3rd party repos? What happens when 3rd party repo maintainers don't like the default policies? Don't they just build repository release packages with scripts which override them setting them back to something they consider sane for their repo? We've been down this rabbit hole before. Fedora controls its repositories.. it does not control 3rd party repositories, we are not going to get into the business of whitelisting or blacklisting anything associated with 3rd party repos making any judgements whatsoever as to the packages in repositories we don't have control over. If this is implemented Fedora won't be doing anything with it at all.
And isn't this duplicate functionality to yum-protectbase and yum-protect-packages that Fedora has...and is not enabled by default?
3)Add voting system to Package Manager: I have a very deep problem with equating votes with trust. I would be more inclined to integrate popcon like functionality or the application usage mechanism that mugshot used to get a crowdsource perspective on how "used" an application package is relative to another...without overloading the meaning of the word "trust." Re
- A server that receives these votes and maintains a list of repos in
sorted order. The distro maintains this. Leave it to the user which repo he wants to add now.
- A server that receives votes and maintains a listing of
repositories in sorted order: We could make modifications to https://admin.fedoraproject.org/pkgdb so that it provides one-click-install links to all packages thus. Similar efforts are at:
The external Fedora community actually had a site like this early on. package tracker or something. But let me be very very clear its going to be very difficult to get this sort of thing officially hosted as an official piece of Fedora infrastructure for the same technical reasons that we can't talk in detail about 3rd party repository packages in the wiki. The only conceivable way you could do this is if each repository hosted its own service instance and packagekit would query each repository's voting information after the repository was configured. Votes are just another form of metadata about packages. We don't host currently recognized 3rd party package metadata centrally, we shouldn't get into the business of hosting more exotic forms of metadata either. Regardless whether its dynamically served from a central service or from mirrored repomd metadata.
And I think you have to make a stronger case for why this has to be a centralized service and not mirrorable repository metadata that fits within the repomd scheme so that it can be mirrored.
And of course none of my comments speak to the value of this concept or the likelihood that Fedora would choose to enable this sort of metadata by default. If its valuable and if Fedora will turn it on, it won't happen unless you decentralize the information in such a way that Fedora does not become responsible for hosting or distributing any metadata about any packages from external repositories.
I can set up a prototype server which accepts these votes and displays reposiories/packages accordingly. Once I have successfully built all the things I have mentioned, I dont mind buying hosting space to host it as a proof of concept.
Please understand that an implementation that is designed as a single service which aggregates repositories from multiple vendors stands a vanishingly small chance of being enabled by default in Fedora for non-technical reasons. I would encourage you to implement your ideas such that each repository can take responsibility for providing its own tagging metadata (abstract enough to be used for other tagging models other than voting).
-jef
packaging@lists.fedoraproject.org