From owner-freebsd-libh Wed Apr 24 11:49:37 2002 Delivered-To: freebsd-libh@freebsd.org Received: from mail1.qc.uunet.ca (mail1.qc.uunet.ca [198.168.54.16]) by hub.freebsd.org (Postfix) with ESMTP id DCBC637B400 for ; Wed, 24 Apr 2002 11:49:02 -0700 (PDT) Received: from Xtanbul ([216.94.147.34]) by mail1.qc.uunet.ca (8.10.2/8.10.2) with ESMTP id g3OImRj07145; Wed, 24 Apr 2002 14:48:28 -0400 Date: Wed, 24 Apr 2002 14:40:49 -0400 Subject: Re: packaging base Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v481) Cc: freebsd-libh@FreeBSD.org To: Mike Meyer From: Antoine Beaupre In-Reply-To: <15558.64002.460056.942779@guru.mired.org> Message-Id: Content-Transfer-Encoding: quoted-printable X-Mailer: Apple Mail (2.481) Sender: owner-freebsd-libh@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Le Mercredi 24 avril 2002, =E0 02:31 , Mike Meyer a =E9crit : > In <342BD734-57AF-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx>, Antoine=20 > Beaupre typed: >> Le Mercredi 24 avril 2002, =E0 02:12 , Mike Meyer a =E9crit : >>> In <0DFF2010-57A8-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx>, Antoine >>> Beaupre typed: >>> Yes, everything needs to be registered. No, installworld doesn't = have >>> to go away. I can see an installworld target that "knows" what >>> packages are part of the base system, and only installs the ones = that >>> are already installed. That's actually cleaner than using make.conf >>> variables. Buildworld can use similar tactics. >> That's a very interesting idea. >> That's why developping pkgAPI is so important: there will be a >> transparent way of getting this kind of information. > > Yeah. The interesting part will be the distinction between updating > the sources and updating the binary. That's why I hoped you had > something real to propose. The current ports mechanism makes upgrading > sources then building and installing them - well, let's say > interesting. There shouldn't be a distinction between updating from a binary or a=20 source package. Let's see we're in the ports paradigm to simplify the explanation: I'd like the ports to avoid installing the port to create the package.=20= The package should be created from the compiled binaries stored in the=20= compilation tree, or stored in a temporary tree. That means we'd need a mapping between the location of the binary in the=20= compilation tree and the installation tree, yes. The advantage of that technique is to, of course, avoid installing=20 unwanted software on a package-building machine. Also, it could ease the package registration if temporary directory=20 scheme is used: the directory could be structured as how a package is=20 internally constructed and the registration would then be easy as=20 registering a package itself. The key here is that all this would be managed by the package system=20 (abstraction made of what it is: libh or current pkgtools/sysinstall).=20= Only the package system knows how a package is formatted. The port would have only to give the compiledir->installdir mappings in=20= a defined format (either using makefile rules or current plists). That could then easily be extended to the base system. >>> This is potentially something I can work on. >> That's why I'm bugging you with this. ;) I just want you to avoid >> thinking that libh is some kind of silver bullet that would take care=20= >> of >> this. It's not taking care of this. > > I believe it should eventually. I hadn't though about pulling the > packages stuff out in parallel, though. It's essential. Libh isn't geared towards messing with the base system=20= right now. It's hard enough as it is. ;) >>> Libh isn't, as I what little I know of tcl is enough to keep me from >>> wanting to learn more. >> libh is more than just tcl. There's a solid C++ API behind all this. > > As if that were an improvement. I'd rather learn TCL than write > C++. The people doing the work like it, so they are free to use what > they want. That it excludes me is my problem, not theirs. LOL! Good luck then. :) Just keep in mind that we need a pkgAPI (that could=20= technically be language independant), and that would take care of=20 interfacing the "ports" (wether they're 3rd party or base) to create=20 packages. libh features will of course influence that API's capabilities, just as=20= current pkgtools functionalities restrict the ports system. A. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message