Date: Wed, 24 Apr 2002 11:14:54 -0500 From: Mike Meyer <mwm-dated-1020096894.f181a3@mired.org> To: Antoine Beaupre <anarcat@anarcat.ath.cx> Cc: hackers@FreeBSD.org, The Anarcat <anarcat@anarcat.dyndns.org>, freebsd-libh@FreeBSD.org Subject: Re: packaging base Message-ID: <15558.55806.422744.851621@guru.mired.org> In-Reply-To: <F371CBE0-5796-11D6-A725-0050E4A0BB3F@anarcat.ath.cx> References: <15558.52046.142372.646281@guru.mired.org> <F371CBE0-5796-11D6-A725-0050E4A0BB3F@anarcat.ath.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
In <F371CBE0-5796-11D6-A725-0050E4A0BB3F@anarcat.ath.cx>, Antoine Beaup= re <anarcat@anarcat.ath.cx> typed: > Le Mercredi 24 avril 2002, =E0 11:12 , Mike Meyer a =E9crit : > > [Replies have been pointed to -hackers to get this off of -stable.]= > [taken to libh] Better. > > In <20020424121651.GA317@lenny.anarcat.dyndns.org>, The Anarcat=20 > > <anarcat@anarcat.dyndns.org> typed: > >> On Wed Apr 24, 2002 at 12:17:37AM -0500, Mike Meyer wrote: > >>> In <20020424050711.GC973@lenny.anarcat.dyndns.org>, The Anarcat=20= > >>> <anarcat@anarcat.dyndns.org> 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 qu= ite > >> 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= =20 > prompting for a simple yes/no question. The issue is really not there= , I=20 > 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. > Libh is developping a UI, fine. But we need to develop a way to packa= ge=20 > base efficiently. Correct. I believe that's part of the libh project. You apparently don't. 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. > >>>> But guess what: libh won't get through if it's not a drop-in > >>>> replacement for sysinstall. > >>> What makes you say that? > >> FUD. Documentation is written for sysinstall and everyone's used t= o > >> it. > > Considering that the installation process is the one that generates= > > the most complaints/suggestions/etc., changing it is certainly a > > must. Yes, we'll need new documentation. I believe there are plans = to > > have them both available for a while. But making it a drop-in would= > > defeat one of the reasons for rewriting it. > I originally agreed with you, but I met some resistance in trying to=20= > convince people so. Did you propose running them both for a while? I think that's a critical step to get people to change. Especially if the libh version offers things the old one doesn't, like a consistent interface. > >>>> In other words, libh doesn't know about the ports collection or > >>>> /usr/src yet, and I don't think it's going to change soon. > >>> Yes, but it will change eventually. > >> I hope not. I prefer keeping the package management system seperat= e > >> from the source management system. > > Wait - source management? What does libh or sysinstall have to do w= ith > > source management, beyond installing the source in the first > > place. Ideally, you want that to be just another package. > Well, that's what I'm saying: libh or sysinstall shouldn't have anyth= ing=20 > to do with source management. :) I never said it should. Is someone else making that claim? > I'm concerned that since libh doesn't currently aim at handling the=20= > current bin.xx brute-force system, it will need base to be packaged i= n=20 > order to install a running system. Correct. > And libh will meet resistance not only from being a brand new system,= =20 > but also at trying to package base, which will break havoc among=20 > 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. > That's why I think the libh vs sysinstall and bin.xx vs base.tgz issu= es=20 > 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. > >>> And yes, it's going to require rewriting the package format to de= al > >>> with the issues needed for working on the base system. > >> I don't think you have proved that point. > > You're right, I haven't. I've been resorting to argument by authori= ty, > > which isn't proof. However, I tend to believe the original author o= f a > > software when he says that something needs to be done a specific wa= y > > to change that system. If you want to argue with the author, jkh's > > address is well-known. > I am not sure jkh would say that libh was written to repackage the ba= se=20 > 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. =09<mike -- Mike Meyer <mwm@mired.org>=09=09=09http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more inform= ation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15558.55806.422744.851621>