Re: CPAN-type thing: specifications, wishes, thoughts?

[Andreas Rottmann]

Paul Raccuglia <address@hidden> 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/>