Paul Raccuglia <pra...@gmail.com> writes: [ Note that I'm writing here with my dorodango developer hat on, not so much as a potential co-mentor. ]
> > My thoughts, specifically, were for the client to be fairly similar in > function to apt-get. (from the user's perspective) > The core commands would be: > > INSTALL package_name -- queries a server (set in configuration > files), gets an absolute link to the package, and a list of > dependencies. Downloads the package, and then any dependencies, and > takes care of unpacking, verifying, compiling, storing, etc. anything > that needs to be done. The package would have to have meta-data > attached in some fashion. > > REMOVE package_name -- just has to remove all the relevant files, and > clean up any references to the package in the storage system. May want > to check dependencies and alert the user. > > UPDATE [package_name] -- could be called to check all packages (by not > specifying a package name) or to update a specific package. Warn the > user of any dependencies that could be broken. > This, in slight variation, is all already implemented in Dorodango; you may want to have a look at its manual[0]. [0] http://home.gna.org/dorodango/manual/ > My thought was that the package manager could, itself, be a package > (but, hopefully, one that would be included by default). > Dorodango is a package; the way you install it works as follows: you download a tarball containing dorodango and its dependencies. After unpacking the tarball, you run 'setup', which sets up the load path for the implementation and invokes it on the doro.sps Scheme program, which then proceeds to install dorodango and all of its dependencies. > I wouldn't imagine that the current code base would need to be > modified a whole lot. > I think the plan was to develop the package manager as an external project, and then integrate it into Guile proper, once its "ready". I imagine Guile core would not need to be modified at all, perhaps modulo some missing features, should that become necessary. > I was thinking that most of this project could be written in Guile. > I think all of it can be written in Scheme, except for some low-level code interfacing with things like libzip (if ZIP is adopted as a package format). > Does that make sense? > > Some thoughts I heard were: > using stowfs to handle storing the packages intelligently > use dorodango to handle most of the acquisition > >From my (obviously strongly biased view), it would be preferable to start with the current dorodango codebase, make sure it works well with Guile (there should not be much work left), and work from there. > > For the server design: I was envisioning a website to navigate > packages (like http://packages.debian.org/stable/). My thought is to > do everything over HTTP (seems like that would work well with > Dorodango). Doesn't seem like a hugely complicated issue? > I started on something like this (i.e. a web interface for dorodango repositories), I'll put the little code I have online and notify you. > Questions about the server: > How would the central repository be maintained? Give trusted > developers the ability to make changes to their personal packages at > will? > This is indeed a good question; the way it works in Debian is that all developers can make changes to any package (by doing a signed upload via FTP), but there are social rules about when it is OK to upload a package one is not the designated maintainer for; see Non-Maintainer Uploads (NMU)[1]. There are also many collaboratively and team-maintained packages where there's not a single maintainer. Perhaps a similiar strategy would work for Guile's repository as well. [1] http://www.debian.org/doc/developers-reference/pkgs.html#nmu > How will packages be nominated / selected for inclusion? > I'd imagine a discussion on guile-devel beforehand would work. Regards, Rotty -- Andreas Rottmann -- <http://rotty.yi.org/>
