From owner-freebsd-libh@FreeBSD.ORG Wed Jun 18 08:40:23 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 356BA37B418; Wed, 18 Jun 2003 08:40:23 -0700 (PDT) Received: from mail2.qc.uunet.ca (mail2.qc.uunet.ca [198.168.54.17]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7CCC243FAF; Wed, 18 Jun 2003 08:40:18 -0700 (PDT) (envelope-from anarcat@espresso-com.com) Received: from xtanbul.studio.espresso-com.com ([216.94.147.57]) by mail2.qc.uunet.ca (8.12.9/8.12.9) with ESMTP id h5IFeCVT029536; Wed, 18 Jun 2003 11:40:12 -0400 Received: from anarcat by xtanbul.studio.espresso-com.com with local (Exim 3.36 #1 (Debian)) id 19Sf2j-0000EF-00; Wed, 18 Jun 2003 11:40:13 -0400 Date: Wed, 18 Jun 2003 11:40:13 -0400 From: The Anarcat To: Samy Al Bahra Message-ID: <20030618154012.GE533@xtanbul> Mail-Followup-To: The Anarcat , Samy Al Bahra , Paul Robinson , freebsd-hackers@freebsd.org, freebsd-libh@freebsd.org References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <20030616191852.GA52694@ussenterprise.ufp.org> <20030618100125.GP20204@iconoplex.co.uk> <1055948691.92188.10.camel@beastie.freebsd.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1055948691.92188.10.camel@beastie.freebsd.local> User-Agent: Mutt/1.5.4i Sender: The Anarcat cc: freebsd-libh@freebsd.org cc: Paul Robinson cc: freebsd-hackers@freebsd.org Subject: 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: Wed, 18 Jun 2003 15:40:23 -0000 (or Yet Another Package Installer Bikeshed) [libh CC'd, for the archives] On mer jun 18, 2003 at 06:23:42 +0300, Samy Al Bahra wrote: > > - Whether the installer is graphical or not is not the issue. Grey boxes on > > a blue background with yellow, red and black text is just plain ugly to a > > society that understands art and interior design. I know you're limited on > > pallet due to the restrictions of the console, but you can make sysinstall > > nicer just by changing the colour scheme. You can make it a hell of a lot > > nicer by making it consistent and functionally useful. Who cares really... Are you going to code it? Are you going to rewrite sysinstall and provide support or are you going to rewrite dialog? I'm getting *really* tired of random people popping up on mailing lists and saying what should and shouldn't be done and complaining about how sysinstall sucks. Yes it sucks! So what? What are you going to do about it? > Just as YaST, a libsysinstall can be provided to provide a standard UI > API for applications to use + various UI plugins (ncurses, QT, GTK, Xaw, > you name it) and configuration modules (users, network, ports, etc...). > Though, before we all get excited about the possibilities of such an > installer, what's happening with libh? Isn't it supposed to deal with > all of sysintall's short-comings? All I see now is a lot of talk and no > code, maybe such discussion should go to libh's mailing list (where we > can talk design there)? Nothing's happening with libh. I suggest you folks to stop talking and start designing. If someone can come with a clean design of a new package manager/installer, then *maybe* something could come out of it, but in all the time I've been interested in package management in BSD, all the talk I've seen has been moot (e.g. I want a GTK installer! I want a pkgAPI!), without any actual code or design. Just talk impeding progress. The only real improvement I'm aware of is portupgrade, which is doing an extraordinaire job considering the architechture, and just popped up without prior useless, endless, close-minded discussions. Let us not forget Colin's binary upgrade software which looks increasingly interesting. libh's dead, folks. It's been dead for a good while now. I was just kicking it to make it look like we could tear something out of this monster. Now back to your scheduled bikeshed. A. From owner-freebsd-libh@FreeBSD.ORG Wed Jun 18 12:20:22 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 8C25337B401; Wed, 18 Jun 2003 12:20:22 -0700 (PDT) Received: from jkh-gw.queasyweasel.com (adsl-64-173-3-158.dsl.sntc01.pacbell.net [64.173.3.158]) by mx1.FreeBSD.org (Postfix) with ESMTP id C9D8E43FA3; Wed, 18 Jun 2003 12:20:21 -0700 (PDT) (envelope-from jkh@queasyweasel.com) Received: from queasyweasel.com (jkh@narcissus.queasyweasel.com [64.173.15.99])h5IJID2J033518; Wed, 18 Jun 2003 12:18:14 -0700 (PDT) (envelope-from jkh@queasyweasel.com) Date: Wed, 18 Jun 2003 12:20:14 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) To: The Anarcat From: Jordan K Hubbard In-Reply-To: <20030618154012.GE533@xtanbul> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) cc: freebsd-libh@freebsd.org cc: freebsd-hackers@freebsd.org cc: Samy Al Bahra cc: Paul Robinson 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: Wed, 18 Jun 2003 19:20:22 -0000 Sorry to hear you say that. It was probably the only effort (which attempted to solve the larger set of issues and not simply peck away at the problem piecemeal) to ever have any code associated with it. On Wednesday, June 18, 2003, at 08:40 AM, The Anarcat wrote: > libh's dead, folks. It's been dead for a good while now. I was just > kicking it to make it look like we could tear something out of this > monster. > -- Jordan K. Hubbard Engineering Manager, BSD technology group Apple Computer From owner-freebsd-libh@FreeBSD.ORG Wed Jun 18 13:04:52 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 AB54037B401; Wed, 18 Jun 2003 13:04:52 -0700 (PDT) Received: from postal.sdsc.edu (postal.sdsc.edu [132.249.20.114]) by mx1.FreeBSD.org (Postfix) with ESMTP id E383A43F75; Wed, 18 Jun 2003 13:04:51 -0700 (PDT) (envelope-from okumoto@ucsd.edu) Received: from multivac.sdsc.edu (IDENT:EJ/U3xYBkL8+qAjEhbeIhAq/f2Ree+kV@multivac.sdsc.edu [132.249.20.57]) h5IK4l109812; Wed, 18 Jun 2003 13:04:47 -0700 (PDT) Received: (from okumoto@localhost) by multivac.sdsc.edu (8.12.5+Sun/8.12.2/submit/3) id h5IK4kxX013079; Wed, 18 Jun 2003 13:04:46 -0700 (PDT) X-Authentication-Warning: multivac.sdsc.edu: okumoto set sender to okumoto@ucsd.edu using -f Sender: okumoto@multivac.sdsc.edu To: Jordan K Hubbard References: From: Max Okumoto Date: 18 Jun 2003 13:04:46 -0700 In-Reply-To: Message-ID: Lines: 27 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii cc: freebsd-libh@freebsd.org cc: Paul Robinson cc: Samy Al Bahra 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: Wed, 18 Jun 2003 20:04:53 -0000 I am still doing work on it... but my normal job has been getting in the way for a while. Max Jordan K Hubbard writes: > Sorry to hear you say that. It was probably the only effort (which > attempted to solve the larger set of issues and not simply peck away > at the problem piecemeal) to ever have any code associated with it. > > On Wednesday, June 18, 2003, at 08:40 AM, The Anarcat wrote: > > > libh's dead, folks. It's been dead for a good while now. I was just > > kicking it to make it look like we could tear something out of this > > monster. > > > -- > Jordan K. Hubbard > Engineering Manager, BSD technology group > Apple Computer > > _______________________________________________ > freebsd-libh@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-libh > To unsubscribe, send any mail to "freebsd-libh-unsubscribe@freebsd.org" From owner-freebsd-libh@FreeBSD.ORG Wed Jun 18 15:25:24 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 2E92837B401; Wed, 18 Jun 2003 15:25:24 -0700 (PDT) Received: from aeimail.aei.ca (aeimail.aei.ca [206.123.6.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id ED40243FDD; Wed, 18 Jun 2003 15:25:21 -0700 (PDT) (envelope-from anarcat@anarcat.ath.cx) Received: from shall.anarcat.ath.cx (esriha8ohmkvvdic@dsl-133-253.aei.ca [66.36.133.253]) by aeimail.aei.ca (8.11.6/8.10.1) with ESMTP id h5IMPFB15052; Wed, 18 Jun 2003 18:25:15 -0400 (EDT) Received: from anarcat.ath.cx (lenny.anarcat.ath.cx [192.168.0.4]) by shall.anarcat.ath.cx (Postfix) with ESMTP id 3C9B9414; Wed, 18 Jun 2003 18:25:14 -0400 (EDT) Message-ID: <3EF0E6DD.8070804@anarcat.ath.cx> Date: Wed, 18 Jun 2003 18:25:33 -0400 From: The Anarcat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030611 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jordan K Hubbard References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-libh@freebsd.org cc: freebsd-hackers@freebsd.org cc: Samy Al Bahra cc: Paul Robinson Subject: Re: YAPIB 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: Wed, 18 Jun 2003 22:25:24 -0000 Well, yes.. I'm sorry too. But I feel that libh's pseudo-existence is more a nuisance right now. The architecture of libh is a bit too big and has this exact problem of putting its hands in too many pieces (as some people have pointed out before). It's really hard to "get into" libh, even for people that actually worked with it before. So libh is always brought back as that "effort in progress" precluding other efforts to build up, the way I see it. So I'm thereby stopping the discourse of saying "libh development is slow". It's stopped. I'd like to see libh's concept recuperated in a fresh implementation instead of the current one, especially since we now have SWIG and don't need to implement our own TCL magic! :) If I ever work again on libh, it'll be a rewrite. That should prove interesting. ;) A. Jordan K Hubbard wrote: >Sorry to hear you say that. It was probably the only effort (which >attempted to solve the larger set of issues and not simply peck away at >the problem piecemeal) to ever have any code associated with it. > >On Wednesday, June 18, 2003, at 08:40 AM, The Anarcat wrote: > > > >>libh's dead, folks. It's been dead for a good while now. I was just >>kicking it to make it look like we could tear something out of this >>monster. >> >> From owner-freebsd-libh@FreeBSD.ORG Wed Jun 18 15:27:33 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 47E0837B401; Wed, 18 Jun 2003 15:27:33 -0700 (PDT) Received: from aeimail.aei.ca (aeimail.aei.ca [206.123.6.14]) by mx1.FreeBSD.org (Postfix) with ESMTP id 26FDD43F75; Wed, 18 Jun 2003 15:27:32 -0700 (PDT) (envelope-from anarcat@anarcat.ath.cx) Received: from shall.anarcat.ath.cx (w1cfoyjlaeuipbsp@dsl-133-253.aei.ca [66.36.133.253]) by aeimail.aei.ca (8.11.6/8.10.1) with ESMTP id h5IMRUB17042; Wed, 18 Jun 2003 18:27:31 -0400 (EDT) Received: from anarcat.ath.cx (lenny.anarcat.ath.cx [192.168.0.4]) by shall.anarcat.ath.cx (Postfix) with ESMTP id 07CA9414; Wed, 18 Jun 2003 18:27:30 -0400 (EDT) Message-ID: <3EF0E766.3020801@anarcat.ath.cx> Date: Wed, 18 Jun 2003 18:27:50 -0400 From: The Anarcat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4b) Gecko/20030611 Thunderbird/0.1a X-Accept-Language: en-us, en MIME-Version: 1.0 To: Max Okumoto References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-libh@freebsd.org cc: freebsd-hackers@freebsd.org cc: Jordan K Hubbard cc: Samy Al Bahra cc: Paul Robinson 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: Wed, 18 Jun 2003 22:27:33 -0000 Max Okumoto wrote: >I am still doing work on it... but my normal job has been >getting in the way for a while. > > Max > > I'm sorry Max. I guess I should have used a bit more diplomacy. But the way I see it, libh was dead even before you got in, the same way it was almost dead before I got in. You've done an awesome job considering the circumstances, but I'm out, for now. ;) No use pretending otherwise. Cheers, A. From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 02:57:34 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 9792337B401; Thu, 19 Jun 2003 02:57:34 -0700 (PDT) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id ADCED43F85; Thu, 19 Jun 2003 02:57:33 -0700 (PDT) (envelope-from paul@hannibal.servitor.co.uk) Received: from paul by hannibal.servitor.co.uk with local (Exim 4.14) id 19SwAl-0001sM-UW; Thu, 19 Jun 2003 10:57:39 +0100 Date: Thu, 19 Jun 2003 10:57:39 +0100 From: Paul Robinson To: The Anarcat , Samy Al Bahra , freebsd-hackers@freebsd.org, freebsd-libh@freebsd.org Message-ID: <20030619095739.GC20204@iconoplex.co.uk> References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <20030616191852.GA52694@ussenterprise.ufp.org> <20030618100125.GP20204@iconoplex.co.uk> <1055948691.92188.10.camel@beastie.freebsd.local> <20030618154012.GE533@xtanbul> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030618154012.GE533@xtanbul> Sender: Paul Robinson 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: Thu, 19 Jun 2003 09:57:34 -0000 On Wed, Jun 18, 2003 at 11:40:13AM -0400, The Anarcat wrote: > > > - Whether the installer is graphical or not is not the issue. Grey boxes on > > > a blue background with yellow, red and black text is just plain ugly to a > > > society that understands art and interior design. I know you're limited on > > > pallet due to the restrictions of the console, but you can make sysinstall > > > nicer just by changing the colour scheme. You can make it a hell of a lot > > > nicer by making it consistent and functionally useful. > > Who cares really... Are you going to code it? Are you going to rewrite > sysinstall and provide support or are you going to rewrite dialog? You're quoting me there. The answer to your question "Are you going to code it?" is "Yes". "Are you going to reqrite sysinstall and provide support or are you going to rewrite dialog?" - neither. I'm fed up of it sitting there too. I'm sick and tired of the discussions. So, after I've moved house this month, got my new machine sorted, and then I'll be sitting down to work on it. I'll do it my way, make it a port, and if others like it, I'll make it easy for them to use in building their own ISOs. I do not see a problem with this. As to what I'm writing, well, I'm going to do the design in about four weeks time, and anybody who is interested can take a look. An announcement will probably go up on -hackers and -libh... > I'm getting *really* tired of random people popping up on mailing > lists and saying what should and shouldn't be done and complaining > about how sysinstall sucks. Yes it sucks! So what? What are you going > to do about it? See above. > I suggest you folks to stop talking and start designing. If someone > can come with a clean design of a new package manager/installer, then > *maybe* something could come out of it, but in all the time I've been > interested in package management in BSD, all the talk I've seen has > been moot (e.g. I want a GTK installer! I want a pkgAPI!), without any > actual code or design. Just talk impeding progress. I want something that works. To be honest, just something that abstracts /usr/ports and makes use of the pkg-descr files would be more useful than the current blank void navigated with cd and more... > The only real improvement I'm aware of is portupgrade, which is doing > an extraordinaire job considering the architechture, and just popped > up without prior useless, endless, close-minded discussions. Let us > not forget Colin's binary upgrade software which looks increasingly > interesting. Yeah, noted. Good stuff. I'm just looking at putting a "friedndly" abstraction over that. > libh's dead, folks. It's been dead for a good while now. I was just > kicking it to make it look like we could tear something out of this > monster. It's not *that* bad is it? :-) -- Paul Robinson From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 04:06:47 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 273AB37B401 for ; Thu, 19 Jun 2003 04:06:47 -0700 (PDT) Received: from genua.rfc-networks.ie (genua.rfc-networks.ie [62.77.182.178]) by mx1.FreeBSD.org (Postfix) with ESMTP id 259B143FA3 for ; Thu, 19 Jun 2003 04:06:46 -0700 (PDT) (envelope-from philip.reynolds@rfc-networks.ie) Received: from tear.domain (unknown [10.0.1.254]) by genua.rfc-networks.ie (Postfix) with ESMTP id 86DDB54897 for ; Thu, 19 Jun 2003 12:06:44 +0100 (IST) Received: by tear.domain (Postfix, from userid 1000) id 3952921150; Thu, 19 Jun 2003 11:06:44 +0000 (GMT) Date: Thu, 19 Jun 2003 11:06:44 +0000 From: Philip Reynolds To: freebsd-libh@freebsd.org Message-ID: <20030619110644.GA69532@rfc-networks.ie> References: <3EF0E6DD.8070804@anarcat.ath.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF0E6DD.8070804@anarcat.ath.cx> X-Operating-System: FreeBSD 4.7-STABLE X-URL: http://www.rfc-networks.ie Subject: Re: YAPIB X-BeenThere: freebsd-libh@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: philip.reynolds@rfc-networks.ie List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 11:06:47 -0000 The Anarcat 39 lines of wisdom included: > Well, yes.. I'm sorry too. But I feel that libh's pseudo-existence is > more a nuisance right now. The architecture of libh is a bit too big and > has this exact problem of putting its hands in too many pieces (as some > people have pointed out before). It's really hard to "get into" libh, > even for people that actually worked with it before. So libh is always > brought back as that "effort in progress" precluding other efforts to > build up, the way I see it. So I'm thereby stopping the discourse of > saying "libh development is slow". It's stopped. > > I'd like to see libh's concept recuperated in a fresh implementation > instead of the current one, especially since we now have SWIG and don't > need to implement our own TCL magic! :) > > If I ever work again on libh, it'll be a rewrite. That should prove > interesting. ;) I'm not sure if my vote counts, but I'd be willing to dedicate a large amount of my spare time to helping with a complete rewrite. In my experience, it takes four of five dedicated people to get a project like this off the ground. Conversations via this list then spark interest and hopefully hard work. If you see no mail in your "libh" folder, it's very easy to lose focus and track. From my own personal experience, I think that lists like this one build up the momentum individuals need to keep working on a project even though they've just finished a hard weeks work, or just came back on vacation or have personal problems at home etc. etc. That and the fact that they have always seemed to flesh out particular ideas and spark new ones. I think I noticed once the mailing list was dead so were a significant amount of contributors and then possibly the project. My 2 cents. Phil. -- Philip Reynolds | RFC Networks Ltd. philip.reynolds@rfc-networks.ie | +353 (0)1 8832063 http://people.rfc-networks.ie/~phil | www.rfc-networks.ie From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 09:41:16 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 72FDD37B404; Thu, 19 Jun 2003 09:41:15 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 505F143FDD; Thu, 19 Jun 2003 09:41:14 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (big.x.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h5JGdttJ062085; Thu, 19 Jun 2003 09:39:56 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3EF1E7EC.3040908@acm.org> Date: Thu, 19 Jun 2003 09:42:20 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Robinson References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: freebsd-libh@freebsd.org cc: Samy Al Bahra Subject: Re: YAPIB (was: Drawing graphics on terminal) X-BeenThere: freebsd-libh@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: kientzle@acm.org List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 16:41:17 -0000 Paul Robinson wrote: > As to what I'm writing, well, I'm going to do the design in about four weeks > time, and anybody who is interested can take a look. An announcement will > probably go up on -hackers and -libh... > .... > I want something that works. To be honest, just something that abstracts > /usr/ports and makes use of the pkg-descr files would be more useful than > the current blank void navigated with cd and more... Paul, When you get ready to do some work, let me know. I've been rewriting the guts of pkg_add for the last month or two. I'm pretty pleased with the results so far, but there's still a lot of code to write. So far: * libtarfile works. This is a library that provides simple iteration over tarfiles. It handles format detection (e.g., both old/Posix/GNU formats and gzip/bzip2/etc compression), can 'extract' entries to disk or to an in-memory buffer, etc. The read support is pretty solid; the write support is just a sketch. * Direct package extraction works. I can open a package file from stdin, disk, ftp, etc, and just install it without having to create a temp directory or any of that nonsense. The idea: extract the packing list into memory, parse it, use it to direct the extraction of the rest of the package. This is _MUCH_ faster than the older pkg_add code. * I've also completely overhauled the packing-list parsing code and a lot of the other basic operations. Next steps: * Requirements handling: I have some recursive requirements handling, but I'm not entirely happy with it. I'm exploring other approaches. * Locating packages. This will probably involve building a DB file in /var/db/pkg to record information about what packages are available from which ftp sites, etc. * Handling conflicts gracefully. This may well involve building a DB file that maps filenames->package names so that an attempt to overwrite a file can be immediately tracked back to the conflicting package. * Building a useful library. I'm being careful to keep code as generic as possible, so it should be pretty simple to put a lot of the useful pieces (packing-list management, locating packages, etc) into a library. Like I said, let me know when you're ready to work on this. My stuff is still pretty rough in some spots, but a lot of it should prove useful to anyone working on install issues. Tim Kientzle From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 10:07:32 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 D88AD37B401; Thu, 19 Jun 2003 10:07:32 -0700 (PDT) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0532543F75; Thu, 19 Jun 2003 10:07:32 -0700 (PDT) (envelope-from paul@hannibal.servitor.co.uk) Received: from paul by hannibal.servitor.co.uk with local (Exim 4.14) id 19T2sw-0002aD-U4; Thu, 19 Jun 2003 18:07:42 +0100 Date: Thu, 19 Jun 2003 18:07:42 +0100 From: Paul Robinson To: Tim Kientzle Message-ID: <20030619170742.GO20204@iconoplex.co.uk> References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF1E7EC.3040908@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: Thu, 19 Jun 2003 17:07:33 -0000 On Thu, Jun 19, 2003 at 09:42:20AM -0700, Tim Kientzle wrote: > When you get ready to do some work, let me know. I've Will do. Just need to move, get DSL installed, and clear down some work and I'm looking at a year of clear weekends and evenings. And this is biting me up inside now... :-) > * libtarfile works. This is a library that provides > simple iteration over tarfiles. It handles format > detection (e.g., both old/Posix/GNU formats and > gzip/bzip2/etc compression), can 'extract' entries > to disk or to an in-memory buffer, etc. The read support > is pretty solid; the write support is just a sketch. v. cool. The other night when I was sitting in the pub sketching on beer mats and cigarette packets to work out what needed doing, one of the first things that sprung to mind was the ability to look inside, if not packages, at least tar files in memory just to get the juicy info out to present the user with choices as to whether that pkg is something they really want, and if so, not have to play around in /tmp or wherever... > * Direct package extraction works. I can open a package > file from stdin, disk, ftp, etc, and just install it > without having to create a temp directory or any of > that nonsense. The idea: extract the packing list > into memory, parse it, use it to direct the extraction > of the rest of the package. This is _MUCH_ faster > than the older pkg_add code. Hah. OK, item number two on the list is struck off. Cool. Looks like I'll be writing a GUI then? :-) > * Requirements handling: I have some recursive requirements > handling, but I'm not entirely happy with it. I'm exploring > other approaches. I'd be interested to know why you're not happy with it - is it the concept of recursiveness over a set of requirements in general you think is flawed, or is it your implementation which is niggling you? Requirements and dependancy tracking/handling are big issues. I've resorted to reading papers on how people have approached it in the past and have some vague ideas, and recursiveness has problems. Recursiveness is always problematic though, no matter what domain you take it too - branching is where I was thinking. > * Locating packages. This will probably involve building > a DB file in /var/db/pkg to record information about > what packages are available from which ftp sites, etc. Instead of retrieving the binary when you do a pkg_add -r perhaps you could end up grabbing a file that described where it could *really* be found (thereby alleviating mirrors from carrying GBs of packages, just the descriptions of where they are), including possible locations on disk, and ultimately, ports ... nothing stopping you shipping this db as part of the base install, or like ports is now, but then we get to crux: Shouldn't pkg_add be an abstraction of ports, with the advantage of grabbing a pre-built binary if it's available, with a command line switch to force a traditional cd /usr/ports/category/package; make install clean ??? At the moment we have ports, and we have packages. Maybe it's time to merge to the benefit of both? > Like I said, let me know when you're ready to work on this. > My stuff is still pretty rough in some spots, but a lot of > it should prove useful to anyone working on install issues. Yeah, certainly, thanks for the heads up. I'm sure I would have been hassling you in a fortnight anyway. :-) -- Paul Robinson From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 11:24:40 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 47DCB37B401; Thu, 19 Jun 2003 11:24:40 -0700 (PDT) Received: from mail1.qc.uunet.ca (mail1.qc.uunet.ca [198.168.54.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3102443FBF; Thu, 19 Jun 2003 11:24:39 -0700 (PDT) (envelope-from anarcat@espresso-com.com) Received: from xtanbul.studio.espresso-com.com ([216.94.147.57]) by mail1.qc.uunet.ca (8.12.9/8.12.9) with ESMTP id h5JILqsB006773; Thu, 19 Jun 2003 14:21:52 -0400 Received: from anarcat by xtanbul.studio.espresso-com.com with local (Exim 3.36 #1 (Debian)) id 19T42i-0000HT-00; Thu, 19 Jun 2003 14:21:52 -0400 Date: Thu, 19 Jun 2003 14:21:52 -0400 From: The Anarcat To: Tim Kientzle Message-ID: <20030619182151.GA1074@xtanbul> Mail-Followup-To: The Anarcat , Tim Kientzle , Paul Robinson , Samy Al Bahra , freebsd-hackers@freebsd.org, freebsd-libh@freebsd.org References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF1E7EC.3040908@acm.org> User-Agent: Mutt/1.5.4i Sender: The Anarcat cc: freebsd-libh@freebsd.org cc: Paul Robinson cc: Samy Al Bahra 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: Thu, 19 Jun 2003 18:24:40 -0000 Bravo! Now this is the talk I like to hear. :) Sorry to have been so negative in my last emails, I see there is good work going on. I have forgotten about you efforts, Tim. Don't give up! A. On jeu jun 19, 2003 at 09:42:20 -0700, Tim Kientzle wrote: > Paul Robinson wrote: > > As to what I'm writing, well, I'm going to do the design in about four weeks > > time, and anybody who is interested can take a look. An announcement will > > probably go up on -hackers and -libh... > > .... > > I want something that works. To be honest, just something that abstracts > > /usr/ports and makes use of the pkg-descr files would be more useful than > > the current blank void navigated with cd and more... > > > Paul, > > When you get ready to do some work, let me know. I've > been rewriting the guts of pkg_add for the last month > or two. I'm pretty pleased with the results so far, > but there's still a lot of code to write. > > So far: > * libtarfile works. This is a library that provides > simple iteration over tarfiles. It handles format > detection (e.g., both old/Posix/GNU formats and > gzip/bzip2/etc compression), can 'extract' entries > to disk or to an in-memory buffer, etc. The read support > is pretty solid; the write support is just a sketch. > * Direct package extraction works. I can open a package > file from stdin, disk, ftp, etc, and just install it > without having to create a temp directory or any of > that nonsense. The idea: extract the packing list > into memory, parse it, use it to direct the extraction > of the rest of the package. This is _MUCH_ faster > than the older pkg_add code. > * I've also completely overhauled the packing-list > parsing code and a lot of the other basic operations. > > Next steps: > * Requirements handling: I have some recursive requirements > handling, but I'm not entirely happy with it. I'm exploring > other approaches. > * Locating packages. This will probably involve building > a DB file in /var/db/pkg to record information about > what packages are available from which ftp sites, etc. > * Handling conflicts gracefully. This may well involve > building a DB file that maps filenames->package names > so that an attempt to overwrite a file can be immediately > tracked back to the conflicting package. > * Building a useful library. I'm being careful to keep code > as generic as possible, so it should be pretty simple > to put a lot of the useful pieces (packing-list management, > locating packages, etc) into a library. > > Like I said, let me know when you're ready to work on this. > My stuff is still pretty rough in some spots, but a lot of > it should prove useful to anyone working on install issues. > > Tim Kientzle > From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 11:28:56 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 25AFC37B401; Thu, 19 Jun 2003 11:28:56 -0700 (PDT) Received: from mail1.qc.uunet.ca (mail1.qc.uunet.ca [198.168.54.16]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4728943FDF; Thu, 19 Jun 2003 11:28:54 -0700 (PDT) (envelope-from anarcat@espresso-com.com) Received: from xtanbul.studio.espresso-com.com ([216.94.147.57]) by mail1.qc.uunet.ca (8.12.9/8.12.9) with ESMTP id h5JIQDsB007012; Thu, 19 Jun 2003 14:26:13 -0400 Received: from anarcat by xtanbul.studio.espresso-com.com with local (Exim 3.36 #1 (Debian)) id 19T46v-0000IJ-00; Thu, 19 Jun 2003 14:26:13 -0400 Date: Thu, 19 Jun 2003 14:26:13 -0400 From: The Anarcat To: Paul Robinson Message-ID: <20030619182612.GB1074@xtanbul> Mail-Followup-To: The Anarcat , Paul Robinson , Samy Al Bahra , freebsd-hackers@freebsd.org, freebsd-libh@freebsd.org References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030619095739.GC20204@iconoplex.co.uk> User-Agent: Mutt/1.5.4i Sender: The Anarcat cc: freebsd-libh@freebsd.org cc: freebsd-hackers@freebsd.org cc: Samy Al Bahra 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: Thu, 19 Jun 2003 18:28:56 -0000 On jeu jun 19, 2003 at 10:57:39 +0100, Paul Robinson wrote: > > libh's dead, folks. It's been dead for a good while now. I was just > > kicking it to make it look like we could tear something out of this > > monster. > > It's not *that* bad is it? :-) It's right now to the point I wouldn't consider writing more code for libh, but I'd reuse the ideas in a smaller, plugin-based, swig-foobar rewrite. So yes, libh is kinda bad, for me at least. And it involves a lot of C++ magic I don't really like. But, as always, if someone feels like picking the horse (wether it's alive or dead I'm never too sure), feel free! The code is there for anyone who dares to look. I've also put up a doxygen framework and there's a bit of design doc, so no, libh's still no so bad since so much people put so much time in it during its long existence. I apologize again for being so brutal to this project which had so high hopes and also to all the people who worked on it. Cheers, A. From owner-freebsd-libh@FreeBSD.ORG Thu Jun 19 12:09:03 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 B1E7F37B401; Thu, 19 Jun 2003 12:09:03 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C3C2D43FA3; Thu, 19 Jun 2003 12:09:02 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (big.x.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h5JJ92tJ062645; Thu, 19 Jun 2003 12:09:02 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3EF20ADE.9000904@acm.org> Date: Thu, 19 Jun 2003 12:11:26 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Robinson References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: kientzle@acm.org List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jun 2003 19:09:04 -0000 Paul Robinson wrote: > On Thu, Jun 19, 2003 at 09:42:20AM -0700, Tim Kientzle wrote: >> * libtarfile works. ... > ... the ability to look inside, if not packages, > at least tar files in memory ... >> * Direct package extraction works. ... In particular, I think that the work I'm doing now should end the discussion about a "better" package format. In short, tar works quite well, thank you very much. Past performance issues were implementation problems, not format problems. > Hah. OK, item number two on the list is struck off. Cool. Looks like I'll be > writing a GUI then? :-) That would seem to be the hard part. I presume you've looked at SUSE's YAST, Debian's APT, and other such tools? >> * Requirements handling: I have some recursive requirements >> handling, but I'm not entirely happy with it. ... > > I'd be interested to know why ... What I have now works as follows: * Start reading the package, extract the packing list, parse it. * Identify any requirements, recursively install those. * Continue reading/installing this package. This has a big problem with network installs. In particular, the download gets stalled while the requirements are added. Over a slow connection, this could leave you with a stalled TCP connection for hours. Not good. One way to address this would be to separate "install-time" requirements from "run-time" requirements. The ports framework already has some concept of this (separates "build-time" from "run-time"), but it doesn't seem quite sufficient. I'm also looking at the 'INDEX' files that the package/ports folks have long been maintaining. By using that, I should be able to generate a full requirements tree up front, then install all of the necessary pieces in order without stalling. Recursive handling will still be needed for installing package files from disk, of course. >> * Locating packages. This will probably involve building >> a DB file in /var/db/pkg to record information about >> what packages are available from which ftp sites, etc. > > Instead of retrieving the binary when you do a pkg_add -r perhaps you could > end up grabbing a file that described where it could *really* be found I'm looking at a couple of approaches. One is to eliminate -r and instead have a simple list of package sources that get inspected. Debian's package management does something similar to this. For example, you might have an /etc/pkg.conf that specifies the following sources: . /usr/packages/distfiles /nfs-server/packages/distfiles ftp://ftp3.freebsd.org/some/path/packages-5.8-release/ ftp://ftp.joesfreebsdsite.org/some/path/packages-5.8-release/ cdrom:"FreeBSD 5.8 CDROM #2":/cdrom/packages By pulling the INDEX data into a DB file, you should be able to look up package locations very quickly indeed. Since the INDEX data includes requirements, you should be able to use this database to expand any package request into a complete list of packages to be installed. In particular, note that this should allow us to support the CD-ROMs more efficiently, by locating packages on particular CD-ROMs and then prompting the user to insert the correct CD. Note that this is simpler than having some form of "master redirect" file, since each repository only needs to track what it provides, not what other repositories might offer. Users can mix and match repositories as needed. > (thereby alleviating mirrors from carrying GBs of packages, just the > descriptions of where they are), including possible locations on disk, and > ultimately, ports ... nothing stopping you shipping this db as part of the > base install, Just having the list of sources is enough. From that, it's easy to pull the INDEX files and generate the full DB. The package tools need to be able to update the DB periodically in any case. > Shouldn't pkg_add be an abstraction of ports, with the advantage of grabbing > a pre-built binary if it's available, with a command line switch to force a > traditional cd /usr/ports/category/package; make install clean ??? No opinion on this one. Perhaps you could formulate a couple of scenarios in which it would be beneficial to be able to mix and match these two? Tim From owner-freebsd-libh@FreeBSD.ORG Fri Jun 20 02:47:20 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 A6C5437B411; Fri, 20 Jun 2003 02:47:20 -0700 (PDT) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id A963C43F75; Fri, 20 Jun 2003 02:47:19 -0700 (PDT) (envelope-from paul@hannibal.servitor.co.uk) Received: from paul by hannibal.servitor.co.uk with local (Exim 4.14) id 19TIUU-0003bl-G9; Fri, 20 Jun 2003 10:47:30 +0100 Date: Fri, 20 Jun 2003 10:47:30 +0100 From: Paul Robinson To: Tim Kientzle Message-ID: <20030620094730.GP20204@iconoplex.co.uk> References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EF20ADE.9000904@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: Fri, 20 Jun 2003 09:47:21 -0000 On Thu, Jun 19, 2003 at 12:11:26PM -0700, Tim Kientzle wrote: > That would seem to be the hard part. I presume you've > looked at SUSE's YAST, Debian's APT, and other such tools? *nods* - nice basis, but not... well... you know. > What I have now works as follows: > * Start reading the package, extract the packing list, parse it. > * Identify any requirements, recursively install those. > * Continue reading/installing this package. To clarfiy your meaning of recursiveness in this context (I can think of another way of doing it "recursively" and I don't have time to peek at code right now), if I want to install package A which requires B and C, B requires D and E, and D requires F, your installer would go Start A -> I need B -> Start B -> I need D -> Start D -> I need F -> Install F -> Install D -> I need E -> Install E -> Install B -> Install C > This has a big problem with network installs. In particular, > the download gets stalled while the requirements are added. > Over a slow connection, this could leave you with a stalled > TCP connection for hours. Not good. In the chain above, if F isn't available for some reason, you have A, B and D all half installed on your machine waiting for a 32Kb library on an un-mirrored FTP server in bulgaria... hmmm... > One way to address this would be to separate "install-time" > requirements from "run-time" requirements. The ports framework > already has some concept of this (separates "build-time" from > "run-time"), but it doesn't seem quite sufficient. If you need it at run time, surely it make sense to grab it at build time? I'm not sure I can see the benefit of seperating it out - you're just going to create a sense of not knowing whether your application is ready to go or not because it's "installed" but doesn't have the kit it needs around it to make it actually *work*.... hmmmm... > I'm looking at a couple of approaches. One is to eliminate -r and instead > have a simple list of package sources that get inspected. Debian's package > management does something similar to this. For example, you might have > an /etc/pkg.conf that specifies the following sources: > . > /usr/packages/distfiles > /nfs-server/packages/distfiles > ftp://ftp3.freebsd.org/some/path/packages-5.8-release/ > ftp://ftp.joesfreebsdsite.org/some/path/packages-5.8-release/ > cdrom:"FreeBSD 5.8 CDROM #2":/cdrom/packages Yup, that's what I was thinking, but you would have such a file for each package, thereby meaning packages can live all over the place. In addition, you wouldn't need that file on the local machine, and for backward compatability, the -r switch grabs a file with that info off of the mirrors, the same way the actual packages are now. It means that in 3-4 years when people are no longer trying to do package management with the current stuff, the mirrors *could* reclaim some disk space. This is likely to be an issue if we want to try and get as much stuff out there as possible run up as pkg's. > installed. In particular, note that this should allow us to support > the CD-ROMs more efficiently, by locating packages on particular CD-ROMs > and then prompting the user to insert the correct CD. There is a minor issue here, around the way I'm planning on helping out the OEM/release engineering stuff as part of the installer effort, in that the package might not be on "FreeBSD 5.8 CDROM #2" but rather on "Dell OEM FreeBSD 6.2 Disk 1", but that's my problem. The more I think about it, the less of an issue it becomes, as I've just written some code in my head around building the release disks that sorts some of this out, but it's an extra req. > Note that this is simpler than having some form of "master redirect" > file, since each repository only needs to track what it provides, > not what other repositories might offer. Users can mix and match > repositories as needed. I'm thinking about backward compatability on the command line for -r that grabs the "master re-direct" file in the format above.. > No opinion on this one. Perhaps you could formulate a couple of > scenarios in which it would be beneficial to be able to mix and > match these two? Where the port exists, but a pre-built binary isn't available, or where somebody wants easy install with his own configure options. So, in your file above, but where you're explicitly discussing a specific package rather than packages in general, you could have a line, for example: ports:/usr/ports/misc/screen:--prefix=/usr/local with command line switches to force the ports option, pass extra args to configure, etc. This means as and administrator you have one 'place' to look after third-party code, you get the advantage of being able to wrap ports into the /var/db/pkg DB, and if the binaries don't exist you can go back to building from scratch. In fact, with a bit more work, you could write a switch to make a package that can then go onto a mirror with nothing more than a command-line switch, based on the port. It also means that if somebody wants to port their application to FreeBSD and distribute a pre-built binary rather than distribute source, they can locally follow the porter's handbook, build their own port, turn it into a package, and then go out and sell it in stores - i.e. it encourages commercial involvement in FreeBSD which is no bad thing. You also suddenly make pkg_add able to handle not only pre-built binaries but grabs all the effort of the ports guys as well. Anyway, I think we're both talking about the same thing here, except you're thinking of a main pkg.conf file, whereas I'm thinking of a DB on disk, or retrieved over the network for EACH PACKAGE, with the benefit of bringing ports in under the package management tree as a fall-back if the binary isn't there, and as an excellent way of helping commercial entities start selling apps for FreeBSD. Just some ideas... -- Paul Robinson From owner-freebsd-libh@FreeBSD.ORG Fri Jun 20 02:50:42 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 4963337B401; Fri, 20 Jun 2003 02:50:42 -0700 (PDT) Received: from hannibal.servitor.co.uk (hannibal.servitor.co.uk [195.188.15.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id 63A1743FCB; Fri, 20 Jun 2003 02:50:41 -0700 (PDT) (envelope-from paul@hannibal.servitor.co.uk) Received: from paul by hannibal.servitor.co.uk with local (Exim 4.14) id 19TIXj-0003cF-6c; Fri, 20 Jun 2003 10:50:51 +0100 Date: Fri, 20 Jun 2003 10:50:51 +0100 From: Paul Robinson To: The Anarcat , Samy Al Bahra , freebsd-hackers@freebsd.org, freebsd-libh@freebsd.org Message-ID: <20030620095051.GQ20204@iconoplex.co.uk> References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> <20030619182612.GB1074@xtanbul> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030619182612.GB1074@xtanbul> Sender: Paul Robinson 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: Fri, 20 Jun 2003 09:50:42 -0000 On Thu, Jun 19, 2003 at 02:26:13PM -0400, The Anarcat wrote: > It's right now to the point I wouldn't consider writing more code for > libh, but I'd reuse the ideas in a smaller, plugin-based, swig-foobar > rewrite. I went back and re-read the notes on the website about libh's design yesterday, first time in a while. It has some good ideas. Definitely lots to pick up on. > So yes, libh is kinda bad, for me at least. And it involves a lot of > C++ magic I don't really like. *shudders*. I was sorting out my flat last night getting ready to move, and I found my old undergrad copy of the second edition K&R book. I hugged it. C++ is for girls. :-) > But, as always, if someone feels like picking the horse (wether it's > alive or dead I'm never too sure), feel free! The code is there for > anyone who dares to look. I've also put up a doxygen framework and > there's a bit of design doc, so no, libh's still no so bad since so > much people put so much time in it during its long existence. Cool. > I apologize again for being so brutal to this project which had so > high hopes and also to all the people who worked on it. It's understandable. Think of it this way - at least the next-gen installer is now likely to get a better name, whoever it is that writes it. :-) -- Paul Robinson From owner-freebsd-libh@FreeBSD.ORG Fri Jun 20 07:05:04 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 5ED7937B401 for ; Fri, 20 Jun 2003 07:05:04 -0700 (PDT) Received: from histidine.utmb.edu (histidine.utmb.edu [129.109.59.80]) by mx1.FreeBSD.org (Postfix) with ESMTP id 611BE43FBD for ; Fri, 20 Jun 2003 07:05:01 -0700 (PDT) (envelope-from bdodson@scms.utmb.EDU) Received: from histidine.utmb.edu (localhost [127.0.0.1]) by histidine.utmb.edu (8.12.9/8.12.9) with ESMTP id h5KE4tjZ018501; Fri, 20 Jun 2003 09:04:55 -0500 (CDT) (envelope-from bdodson@histidine.utmb.edu) Received: (from bdodson@localhost) by histidine.utmb.edu (8.12.9/8.12.9/Submit) id h5KE4qWc018498; Fri, 20 Jun 2003 09:04:52 -0500 (CDT) From: "M. L. Dodson" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16115.5252.652966.23693@histidine.utmb.edu> Date: Fri, 20 Jun 2003 09:04:52 -0500 To: Paul Robinson In-Reply-To: <20030620095051.GQ20204@iconoplex.co.uk> References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> <20030619182612.GB1074@xtanbul> <20030620095051.GQ20204@iconoplex.co.uk> X-Mailer: VM 7.14 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid cc: freebsd-libh@freebsd.org cc: Samy Al Bahra Subject: Re: YAPIB (was: Drawing graphics on terminal) X-BeenThere: freebsd-libh@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: bdodson@scms.utmb.EDU List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 14:05:04 -0000 [-hackers trimmed.] Paul Robinson writes: > On Thu, Jun 19, 2003 at 02:26:13PM -0400, The Anarcat wrote: > > > It's right now to the point I wouldn't consider writing more code for > > libh, but I'd reuse the ideas in a smaller, plugin-based, swig-foobar > > rewrite. > > I went back and re-read the notes on the website about libh's design > yesterday, first time in a while. It has some good ideas. Definitely lots to > pick up on. > > > So yes, libh is kinda bad, for me at least. And it involves a lot of > > C++ magic I don't really like. > > *shudders*. I was sorting out my flat last night getting ready to move, and > I found my old undergrad copy of the second edition K&R book. I hugged it. > C++ is for girls. :-) > Sorry to unlurk and run, but I think a perusal of the history of the libh project will show that the main gui toolkit candidates, qt and tvision, were written in C++. I don't think it was any thing more complicated than that. Jordan can clarify if he wishes, but I've been lurking as a kind of libh "groupie" for a long time, and I can't remember any posting that said "We're going to do this in C++". Bud Dodson, who would like to see this project resurrected, but hopes it is not written in C++ with tcl as the scripting language, and who is not enough of a programmer to contribute directly. > > But, as always, if someone feels like picking the horse (wether it's > > alive or dead I'm never too sure), feel free! The code is there for > > anyone who dares to look. I've also put up a doxygen framework and > > there's a bit of design doc, so no, libh's still no so bad since so > > much people put so much time in it during its long existence. > > Cool. > > > I apologize again for being so brutal to this project which had so > > high hopes and also to all the people who worked on it. > > It's understandable. Think of it this way - at least the next-gen installer > is now likely to get a better name, whoever it is that writes it. :-) > > -- > Paul Robinson -- M. L. Dodson bdodson@scms.utmb.edu 409-772-2178 FAX: 409-772-1790 From owner-freebsd-libh@FreeBSD.ORG Fri Jun 20 10:35:41 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 D11CC37B401; Fri, 20 Jun 2003 10:35:41 -0700 (PDT) Received: from kientzle.com (h-66-166-149-50.SNVACAID.covad.net [66.166.149.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C7B1843F75; Fri, 20 Jun 2003 10:35:40 -0700 (PDT) (envelope-from kientzle@acm.org) Received: from acm.org (big.x.kientzle.com [66.166.149.54]) by kientzle.com (8.12.9/8.12.9) with ESMTP id h5KHZWtJ065513; Fri, 20 Jun 2003 10:35:40 -0700 (PDT) (envelope-from kientzle@acm.org) Message-ID: <3EF34676.9060708@acm.org> Date: Fri, 20 Jun 2003 10:37:58 -0700 From: Tim Kientzle User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0.1) Gecko/20021005 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Robinson References: <200306162015.06836.nakal@web.de> <20030616151024.0616e1e4.eaja@erols.com> <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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit 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 Reply-To: kientzle@acm.org List-Id: Dedicated to libh code development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jun 2003 17:35:42 -0000 Paul Robinson wrote: > ... if I want to install package A which requires B and C, B > requires D and E, and D requires F, your installer would go Start A -> I > need B -> Start B -> I need D -> Start D -> I need F -> Install F -> Install > D -> I need E -> Install E -> Install B -> Install C > .... > In the chain above, if F isn't available for some reason, you have A, B and > D all half installed on your machine waiting for a 32Kb library on an > un-mirrored FTP server in bulgaria... hmmm... 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. >>One way to address this would be to separate "install-time" >>requirements from "run-time" requirements. > > If you need it at run time, surely it make sense to grab it at build time? > I'm not sure I can see the benefit of seperating it out The benefit being that only "install time" requirements actually need to be installed recursively. Run-time requirements can be queued up and installed afterwards. This reduces the likelihood that network installs will get stalled for long periods of time. Of course, this doesn't really solve the underlying problem. As I said, if you can get requirements information from somewhere else (the INDEX files available on CDs and FTP sites), then you can build a full, properly sorted list of packages and install them in order without any stalls. That's the approach I'm planning to pursue next. > I'm thinking about backward compatability on the command line for -r that > grabs the "master re-direct" file in the format above.. 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. 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. 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. I can see where a flag to inhibit network downloads might be useful. (I'm sitting on an airplane with my laptop and I _think_ I downloaded everything I needed before I left the office.) However, flags like -r that select individual sources just strike me as rather pointless. >>Perhaps you could formulate a couple of scenarios in which it would >>be beneficial to be able to mix and match these two? > > Where the port exists, but a pre-built binary isn't available, Okay, I can see some merit in having pkg_add mine the ports system as a source of packages. Basically, if the ports version is the newest, provide the user an option of installing from there. 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. 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?) > ... or where somebody wants easy install with his own configure options. If people really want their own config options, then they should work with the port directly. There's no feasible way to wrap every possible port option into a single tool. The whole point of the ports framework is the extreme flexibility it provides. > ... you get the advantage of being able to wrap ports > into the /var/db/pkg DB ... you could write a > switch to make a package ... based on the port. 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. > ... whereas I'm thinking of a DB on disk, or > retrieved over the network for EACH 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.) Tim Kientzle