Date: Wed, 24 Apr 2002 14:40:49 -0400 From: Antoine Beaupre <anarcat@anarcat.ath.cx> To: Mike Meyer <mwm-dated-1020105090.c714a4@mired.org> Cc: freebsd-libh@FreeBSD.org Subject: Re: packaging base Message-ID: <CC0445CE-57B2-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx> In-Reply-To: <15558.64002.460056.942779@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Le Mercredi 24 avril 2002, à 02:31 , Mike Meyer a écrit : > In <342BD734-57AF-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx>, Antoine > Beaupre <anarcat@anarcat.ath.cx> typed: >> Le Mercredi 24 avril 2002, à 02:12 , Mike Meyer a écrit : >>> In <0DFF2010-57A8-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx>, Antoine >>> Beaupre <anarcat@anarcat.ath.cx> 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 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. The package should be created from the compiled binaries stored in the compilation tree, or stored in a temporary tree. That means we'd need a mapping between the location of the binary in the compilation tree and the installation tree, yes. The advantage of that technique is to, of course, avoid installing unwanted software on a package-building machine. Also, it could ease the package registration if temporary directory scheme is used: the directory could be structured as how a package is internally constructed and the registration would then be easy as registering a package itself. The key here is that all this would be managed by the package system (abstraction made of what it is: libh or current pkgtools/sysinstall). Only the package system knows how a package is formatted. The port would have only to give the compiledir->installdir mappings in 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 >> 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 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 technically be language independant), and that would take care of interfacing the "ports" (wether they're 3rd party or base) to create packages. libh features will of course influence that API's capabilities, just as 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC0445CE-57B2-11D6-AE88-0050E4A0BB3F>