[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Need advice pertaining to GSoC proposal



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/50de9e16d5407b9c

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.

-- 
Be Intelligent, Use GNU/Linux

http://debayanin.googlepages.com/
http://debayan.wordpress.com
http://lug.nitdgp.ac.in


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]