From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=DATE_IN_PAST_12_24,DMARC_NONE, INVALID_DATE,MAILING_LIST_MULTI autolearn=no autolearn_force=no version=4.0.0 Received: from femail2.rdc1.on.home.com ([24.2.9.89]) by cvs.gentoo.org with esmtp (Exim 3.30 #1) id 15JKlE-0001LP-00 for gentoo-dev@cvs.gentoo.org; Sun, 08 Jul 2001 14:02:32 -0600 Received: from home.com ([24.101.168.108]) by femail2.rdc1.on.home.com (InterMail vM.4.01.03.20 201-229-121-120-20010223) with ESMTP id <20010708200135.BXLQ21541.femail2.rdc1.on.home.com@home.com> for ; Sun, 8 Jul 2001 13:01:35 -0700 Message-ID: <3B48B633.ED2D28CC@home.com> From: DDavies X-Mailer: Mozilla 4.77 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: gentoo-dev@cvs.gentoo.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [gentoo-dev] Dan: about your version question Sender: gentoo-dev-admin@cvs.gentoo.org Errors-To: gentoo-dev-admin@cvs.gentoo.org X-BeenThere: gentoo-dev@cvs.gentoo.org X-Mailman-Version: 2.0 Precedence: bulk Reply-To: gentoo-dev@cvs.gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux development list List-Unsubscribe: , List-Archive: Date: Sun Jul 8 14:03:01 2001 X-Original-Date: Sun, 08 Jul 2001 15:36:19 -0400 X-Archives-Salt: 6278a0f6-87d4-4422-a9af-b6b1051af064 X-Archives-Hash: b3718f7d07e60625485a13ae83bf2ef0 Hi, Dan Well Ive been around here quite a long time, and I can fill you in on a couple details. FIrst of all, Daniel has noted that he plans to re-implement the download system. I have personally made the case here in the past (we're talking like 4 months ago now) for lukemftp to be incorporated into the download system. The portage fetch subsystem totally needs rethinking, and Im sure there are many issues Daniel is working on to improve it. One of these is the broken download, corrupt download thing. This shouldnt be hard to fix since resuming file transfers is easy to do, and well supported by the various fetch programs out there. Another thing is the fact that SRC_URI needs to have USE dependency support added, so files not needed for building arent downloaded. Then theres the issue about perhaps extending .ebuild scripts to possibly have a src_fetch() function. In this way, you could write CVS or CVSup commands to get source, and package it up or whatever you want. Then developers could get the benefit of being able to have CVS source trees merged into their filesystem with all the nice benefits of portage.. like the MD5 package database, the config file protection and everything else. Of course my personal preference would be to extend SRC_URI to handle cvs:// and maybe cvsup:// URL types! Now that would be cool. Come up with a simple syntax for such a thing.. wow then portage would be the coolest thing for linux development since gcc. Of course Im just the sucker to volunteer help come up with such a thing. The need for this type of thing is pretty clear in my opinion, I was just waiting untill somebody else spoke up to spark interest. Now Im not alone. heheh. What other ideas are out there for improving the download subsystem? Is the wget.fetch, lukemftp.fetch thing still being thought out?