From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andreas Rottmann Newsgroups: gmane.lisp.guile.devel Subject: Re: CPAN-type thing: specifications, wishes, thoughts? Date: Wed, 20 Apr 2011 16:06:07 +0200 Message-ID: <8739ldkofk.fsf@gmx.at> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1303308402 20518 80.91.229.12 (20 Apr 2011 14:06:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 20 Apr 2011 14:06:42 +0000 (UTC) Cc: guile-devel@gnu.org To: Paul Raccuglia Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Apr 20 16:06:36 2011 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QCY37-0003hC-1F for guile-devel@m.gmane.org; Wed, 20 Apr 2011 16:06:33 +0200 Original-Received: from localhost ([::1]:37541 helo=lists2.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCY36-0007jR-47 for guile-devel@m.gmane.org; Wed, 20 Apr 2011 10:06:32 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:33772) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QCY34-0007jI-7M for guile-devel@gnu.org; Wed, 20 Apr 2011 10:06:31 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QCY2z-00045P-K3 for guile-devel@gnu.org; Wed, 20 Apr 2011 10:06:30 -0400 Original-Received: from mailout-de.gmx.net ([213.165.64.23]:54098) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1QCY2z-00045H-6I for guile-devel@gnu.org; Wed, 20 Apr 2011 10:06:25 -0400 Original-Received: (qmail invoked by alias); 20 Apr 2011 14:06:22 -0000 Original-Received: from 83-215-154-5.hage.dyn.salzburg-online.at (EHLO nathot.lan) [83.215.154.5] by mail.gmx.net (mp013) with SMTP; 20 Apr 2011 16:06:22 +0200 X-Authenticated: #3102804 X-Provags-ID: V01U2FsdGVkX185dJ9PVXo5fG4glTNfQ7OwZbys3Cto44aOoGNNqC n5dfiIwCSDK7l4 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by nathot.lan (Postfix) with ESMTP id 704DE3A69B; Wed, 20 Apr 2011 16:06:17 +0200 (CEST) Original-Received: from nathot.lan ([127.0.0.1]) by localhost (nathot.lan [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xFbhhwXEYUew; Wed, 20 Apr 2011 16:06:08 +0200 (CEST) Original-Received: from thinky (localhost.localdomain [127.0.0.1]) by nathot.lan (Postfix) with ESMTP id CB9133A696; Wed, 20 Apr 2011 16:06:07 +0200 (CEST) In-Reply-To: (Paul Raccuglia's message of "Tue, 12 Apr 2011 23:01:08 -0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-Y-GMX-Trusted: 0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 213.165.64.23 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:12296 Archived-At: Paul Raccuglia 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 --