In <[EMAIL PROTECTED]>, Antoine Beaupre
<[EMAIL PROTECTED]> typed:
> Le Mercredi 24 avril 2002, à 11:12 , Mike Meyer a écrit :
> > [Replies have been pointed to -hackers to get this off of -stable.]
> [taken to libh]
Better.
> > In <[EMAIL PROTECTED]>, The Anarcat
> > <[EMAIL PROTECTED]> typed:
> >> On Wed Apr 24, 2002 at 12:17:37AM -0500, Mike Meyer wrote:
> >>> In <[EMAIL PROTECTED]>, The Anarcat
> >>> <[EMAIL PROTECTED]> 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 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.
> 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. 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 to
> >> 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
> 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 seperate
> >> from the source management system.
> > Wait - source management? What does libh or sysinstall have to do with
> > 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 anything
> 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
> current bin.xx brute-force system, it will need base to be packaged in
> order to install a running system.
Correct.
> 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.
> 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.
> >>> And yes, it's going to require rewriting the package format to deal
> >>> 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 authority,
> > which isn't proof. However, I tend to believe the original author of a
> > software when he says that something needs to be done a specific way
> > 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 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.
<mike
--
Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
