From owner-freebsd-libh Wed Apr 24 10:33:19 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 B2D7237B483 for ; Wed, 24 Apr 2002 10:31:37 -0700 (PDT) Received: from Xtanbul ([216.94.147.34]) by mail1.qc.uunet.ca (8.10.2/8.10.2) with ESMTP id g3OHVXj27002; Wed, 24 Apr 2002 13:31:34 -0400 Date: Wed, 24 Apr 2002 13:23:55 -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.55806.422744.851621@guru.mired.org> Message-Id: <0DFF2010-57A8-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 [-hackers cc removed] Le Mercredi 24 avril 2002, =E0 12:14 , Mike Meyer a =E9crit : > In , Antoine=20 > Beaupre typed: >> Le Mercredi 24 avril 2002, =E0 11:12 , Mike Meyer a =E9crit : >>> In <20020424121651.GA317@lenny.anarcat.dyndns.org>, The Anarcat >>> typed: >>>> On Wed Apr 24, 2002 at 12:17:37AM -0500, Mike Meyer wrote: >>>>> In <20020424050711.GC973@lenny.anarcat.dyndns.org>, The Anarcat >>>>> typed: >>>>> That one's not the problem. The problem is catting together many >>>>> *floppies* to get a package prior to actually installing it. = That's >>>>> not quite so simple. >>>> I could see a simple shell script deal with that. I think it is = quite >>>> simple. >>> Your simple shell script has to prompt for floppies. That needs UI >>> code. The people who know have decided that the current UI code = isn't >>> up to snuff. Hence libh. >> Come on.. The current package system and sysinstall are quite good at >> prompting for a simple yes/no question. The issue is really not=20 >> there, I >> think. > > I'm not really sure - I haven't poked at the source to see what would > have to change to make all that work. a simple read() (in C) or read(1) (in sh) would do. :) >> Libh is developping a UI, fine. But we need to develop a way to = package >> base efficiently. > > Correct. I believe that's part of the libh project. You apparently > don't. no, i don't. packaging the base system would imply modifying the base=20 system build system, and libh is developped apart from the base system. > I actually think you could start this project and use the libh > list to communicate the work. If you can make it work with the current > sysinstall, great. If not - well, you'll at least have the package > system ready for when libh gets there. that's exactly what I'm saying, except that the libh context isn't=20 necessarly the proper one. There's also the binup project involved. >> 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=20 seperate the different parts of the tree clearly and isolate their=20 dependencies and let the developper make install where he wants. Using=20= variables, we'll end up with hundreds of them. It will be a maintenance=20= nightmare. installworld is somehow doomed to go in the new scheme, as everything=20 will be a package and the line between base and ports will be blurred.=20= Everything installed through this procedure will have to be registered=20= through the package system. >> That's why I think the libh vs sysinstall and bin.xx vs base.tgz = issues >> must be separated. > > As I pointed out above, that separation doesn't have to mean pulling > the bin.xxx vs. base.tgz stuff out of libh. The two can happen in > parallel. my point exactly. And that's why the base packaging is somehow=20 irrelevant to libh, as libh could technically be used to install=20 anything that would be packaged. >> I am not sure jkh would say that libh was written to repackage the = base >> system. It seemed kind of implicit in the design documents, wasn't = it? > > No, he wouldn't say libh was written to repackage the base system. He > would say that repackaging the base system was one of the goals of the > libh project. ah. >