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, =E0 02:31 , Mike Meyer a =E9crit : > In <342BD734-57AF-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx>, Antoine=20 > Beaupre <anarcat@anarcat.ath.cx> typed: >> Le Mercredi 24 avril 2002, =E0 02:12 , Mike Meyer a =E9crit : >>> 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=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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CC0445CE-57B2-11D6-AE88-0050E4A0BB3F>