On Thu, 2009-04-02 at 03:09 +0530, Debayan Banerjee wrote: > 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. Indeed, there are two steps: 1) I trust XYZ, to get packages from. 2) I install package Foo from XYZ. ...it's possible these steps could be done within a single command or made more userfriendly in many ways, but you still need two steps. > 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) We already have a format for repository metadata, why do you want to use a different one? > , 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. It can't do this "automatically", it still needs the user to sign off on the two distinct steps above. [...] > 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/. This was rejected previously due to not being secure, what has changed? > 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" We already have this, it's called GPG key management. > 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. Why do you think votes (esp. those by users) and trust are related? I guess it's not a _terrible_ hint, but it's surely not a good one either. We don't do Fedora package reviews by having everyone vote, so I don't see why we'd want to do the same thing for (expandable) sets of packages. > 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. Given that Fedora, as a distro., don't ship rpmfusion-free-release (for both legal and non-legal reasons) ... why do you think they will maintain this list? -- James Antill <james@xxxxxxxxxxxxxxxxx> Fedora -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
