From owner-freebsd-libh Wed Apr 24 11:22:54 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 B651A37B41C for ; Wed, 24 Apr 2002 11:22:49 -0700 (PDT) Received: from Xtanbul ([216.94.147.34]) by mail1.qc.uunet.ca (8.10.2/8.10.2) with ESMTP id g3OIMjj02477; Wed, 24 Apr 2002 14:22:46 -0400 Date: Wed, 24 Apr 2002 14:15:05 -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.62884.852620.270991@guru.mired.org> Message-Id: <342BD734-57AF-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx> 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:12 , Mike Meyer a =E9crit : > In <0DFF2010-57A8-11D6-AE88-0050E4A0BB3F@anarcat.ath.cx>, Antoine=20 > Beaupre typed: >>>> And libh will meet resistance not only from being a brand new = system, >>>> but also at trying to package base, which will break havoc among >>>> developpers. >>> >>> How many developers use sysinstall, vs. rebuilding from source? = Those >>> are the only ones who are liable to care. If it's done right, then = the >>> new sysinstall should have packages defined by the NO* variables in >>> /etc/defaults/make.conf, and should set the appropriate flags in >>> /etc/make.conf for each part you don't load. >> Please no. Please let's get rid of those variables. Please lets just >> seperate the different parts of the tree clearly and isolate their >> dependencies and let the developper make install where he wants. = Using >> variables, we'll end up with hundreds of them. It will be a = maintenance >> nightmare. > > Now you're talking about breaking "make buildworld", and that will > generate a lot of resistance. It's not clear what you're proposing > replacing it with, except for some portupgrade-like utility. Yeah.. I guess I just threw this as a thought. Forget it. :) >> installworld is somehow doomed to go in the new scheme, as everything >> will be a package and the line between base and ports will be = blurred. >> Everything installed through this procedure will have to be = registered >> through the package system. > > 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=20 transparent way of getting this kind of information. > But that's all *very* vague. A solid proposal is in order. Since > you've apparently done more thinking on this than me, do you have one > in mind? *Nothing*. I've been thinking about this long and large, and I didn't=20 see any clean way of packaging the base system apart using the ports=20 collection which obviously, isn't really a good solution. > This is potentially something I can work on. That's why I'm bugging you with this. ;) I just want you to avoid=20 thinking that libh is some kind of silver bullet that would take care of=20= this. It's not taking care of this. packaging of the base system, once done, will easily be integrated to=20 libh. I suggest you start attacking the problem by making abstraction of=20= the floppy problem. I see it as just a technical quirk. I'd like to see a finer-grained packaging than just one big "bin"=20 though. :) > Libh isn't, as I what little I know of tcl is enough to keep me from=20= > wanting to learn more. libh is more than just tcl. There's a solid C++ API behind all this. > However, something like tcl is required, because part of the new > port/package system is a safe way to encode actions on packages. yeah. TCL or another sandbox thing to allow safe execution of packages. a. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message