From owner-freebsd-libh@FreeBSD.ORG Mon Jun 23 02:48:01 2003 Return-Path: Delivered-To: freebsd-libh@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F6EA37B401; Mon, 23 Jun 2003 02:48:01 -0700 (PDT) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id B365E43FCB; Mon, 23 Jun 2003 02:48:00 -0700 (PDT) (envelope-from paul@hannibal.servitor.co.uk) Received: from paul by hannibal.servitor.co.uk with local (Exim 4.14) id 19UNvn-0008TY-Ry; Mon, 23 Jun 2003 10:48:11 +0100 Date: Mon, 23 Jun 2003 10:48:11 +0100 From: Paul Robinson To: Tim Kientzle Message-ID: <20030623094811.GG15584@iconoplex.co.uk> References: <20030616191852.GA52694@ussenterprise.ufp.org> <20030618100125.GP20204@iconoplex.co.uk> <1055948691.92188.10.camel@beastie.freebsd.local> <20030618154012.GE533@xtanbul> <20030619095739.GC20204@iconoplex.co.uk> <3EF1E7EC.3040908@acm.org> <20030619170742.GO20204@iconoplex.co.uk> <3EF20ADE.9000904@acm.org> <20030620094730.GP20204@iconoplex.co.uk> <3EF34676.9060708@acm.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF34676.9060708@acm.org> Sender: Paul Robinson cc: freebsd-libh@freebsd.org cc: freebsd-hackers@freebsd.org Subject: Re: YAPIB (was: Drawing graphics on terminal) X-BeenThere: freebsd-libh@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jun 2003 09:48:02 -0000 On Fri, Jun 20, 2003 at 10:37:58AM -0700, Tim Kientzle wrote: > Yes, meanwhile, the server providing B times out your connection, > the whole install gets rolled back, and you have to start again > from scratch. Not pretty. Quite. Unless you ship all dependancies as part of the package in the same file, which kind of defeats the object of having packages. > Hmmm.. There are two problems here: The first is maintenance. Suppose > a couple of friends of mine set up a site with packages that they're > building. I want to be able to add their site to my personal list of > package sources without having to go bug the "Official FreeBSD FTP Package > Uber-Person" to get their packages added to the master file. This > means that my pkg_add needs to be able to search multiple sites no > matter what. Fair enough. So, if I state "pkg_add -r apache" it's going to grab the file from the main site, or the local DB for apache. If I were to specify "pkg_add -r ftp://some.site.somewhere.com/~myfriend/pkgs/apache.tar.bz2" or whatever, then obviously I'm not going to look at the local DB for apache, or try and get the re-direct file off of the FreeBSD server - I'm going straight for the pkg I've specified. > Don't rely on a single definitive source of package information. > Having some sort of redirect support in the INDEX file is fine > and easy to add, but you still need the client to be able to search > multiple sources. This is one thing the Debian folks got right. I think what I'm talking about allows for that. It allows for a big local database, a remote database maintained by FBSD folks, a smaller footprint than the current packages take AND allows for installs of remote or local packages that are not part of that schema. In addition, it'll also try and build the port if it can't find the pkg. > The other problem is that the current -r is fundamentally limited > (to a single network source) and draws a rather pointless distinction > (you get to search either disk sources with PKG_PATH _OR_ you get > to search a network source, but not both). I'd like to erase that > distinction so that pkg_add just searches all available sources. That's what I'm saying. -r no longer grabs the package from the remote server, it grabs a file from the remote server that tells you where the packages may be, and failing that, what the port is. Equally, without -r it searches the local database, unless I specifically name a file in the form ftp://blah.com/package.tar.bz2 or ~/mypackage.tar.bz2 or whatever, but if I just "pkg_add apache" it'll search local DBs in the form similar to my last e-mail. > Easy to do, but I'd be cautious with this. Building OpenOffice or KDE from > ports is an adventure that most people would rather skip, and pkg_add > shouldn't > be automatically starting a port compile just because it notices that > there's > a 1.0.3 port and a 1.0.2 package. Yup. But we can alter the files for those special cases where we know a port takes 14 hours to build, 2Gb of disk space and 512Mb RAM, and say "are you REALLY sure you want to do this?". Besides, as far as the example with the plane is concerned, within 6 months, we'll all have 10Mb/sec to our seats, surely? :-) > Of course, there's also some merit to working on this issue from > the other side. In many cases, port requirements could easily be > satisfied from packages. (How many people really need to compile > the JPEG library?) Sam Smith e-mailed me over the weekend with a patch he made to the OpenBSD ports where you could specify FROM_PACKAGES or FROM_SOURCE either on the command line with make, or in the conf file and then ports kind of does what we're talking about. So, if by default you have in mk.conf (or whatever it is, memory is poor on Monday mornings) you have FROM_PACKAGES=yes when you do "cd /usr/ports/graphics/jpeg; make install" it tries to find a package before it builds the source. This is sensible. > All of this already exists. Ports already register with the /var/db/pkg > DB and the ports framework already has make targets to build packages > from any port. Yeah, I'd forgotten about the "package" command on ports. Never used it, but kind of remembered from the man page, which I've just refreshed my memory of. Because of this though, there is no excuse for a port to be ahead of a package. It wouldn't take much to cvs the ports collection on a daily basis, track those ports that are added or updated and automatically build a package. > This already exists; it's called /usr/ports. See the pkg-* files, > the Makefile, etc. Those already exist, and can be mined by other > tools. (Look at crunchgen for some tips on how to effectively mine > data from conforming Makefiles.) No, no, no, no. ports is not what I'm talking about. I know it seems daft, but I think I've lost you somewhere here. Maybe I can get what I want from taking Sam's patch and adapting it for FreeBSD, but it's still not quite what I'm talking about. Let me do some work, and then during the week I'll send you some design docs off-list, and maybe that'll explain... -- Paul Robinson From owner-freebsd-libh@FreeBSD.ORG Fri Jun 27 00:33:19 2003 Return-Path: Delivered-To: freebsd-libh@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E6C5437B401 for ; Fri, 27 Jun 2003 00:33:18 -0700 (PDT) Received: from barry.mail.mindspring.net (barry.mail.mindspring.net [207.69.200.25]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7C4A743FF7 for ; Fri, 27 Jun 2003 00:33:18 -0700 (PDT) (envelope-from david@usermode.org) Received: from h-68-164-77-250.snvacaid.covad.net ([68.164.77.250] helo=brandybuck.home) by barry.mail.mindspring.net with esmtp (Exim 3.33 #1) id 19VnjR-0006MF-00 for freebsd-libh@freebsd.org; Fri, 27 Jun 2003 03:33:18 -0400 From: David Johnson Organization: Usermode To: freebsd-libh@freebsd.org Date: Fri, 27 Jun 2003 00:38:05 -0700 User-Agent: KMail/1.5.2 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200306270038.05094.david@usermode.org> Subject: libh newbie X-BeenThere: freebsd-libh@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jun 2003 07:33:19 -0000 Just posting to say hello. I've been poking around the archives for almost a year now just keeping track of progress. Unfortunately there hasn't been much. Last week's blip in posts was interesting so I'm joining to get a closer look at things. -- David Johnson ___________________ http://www.usermode.org