Date: Mon, 29 Oct 2001 10:53:21 -0000 From: Paul Richards <paul@freebsd-services.com> To: The Anarcat <anarcat@anarcat.dyndns.org> Cc: Alexander Langer <alex@big.endian.de>, Josef Karthauser <joe@tao.org.uk>, "Simon L. Nielsen" <simon@nitro.dk>, Eric Melville <eric@FreeBSD.org>, binup@FreeBSD.org, libh@FreeBSD.org Subject: Re: current project steps Message-ID: <125480000.1004352801@lobster.originative.co.uk> In-Reply-To: <20011028185945.E71544@shall.anarcat.dyndns.org> References: <20011026165952.D11804@shall.anarcat.dyndns.org> <20011026221254.A36515@tao.org.uk> <20011026172027.F11804@shall.anarcat.dyndns.org> <20011026223033.A44573@tao.org.uk> <20011027131726.A68253@shall.anarcat.dyndns.org> <20011027210157.D1534@tao.org.uk> <20011028100459.A40262@fump.kawo2.rwth-aachen.de> <361480000.1004271794@lobster.originative.co.uk> <20011028132639.A71003@shall.anarcat.dyndns.org> <11770000.1004307790@lobster.originative.co.uk> <20011028185945.E71544@shall.anarcat.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--On Sunday, October 28, 2001 18:59:45 -0500 The Anarcat <anarcat@anarcat.dyndns.org> wrote: > On Sun Oct 28, 2001 at 10:23:10PM -0000, Paul Richards wrote: >> --On Sunday, October 28, 2001 13:26:40 -0500 The Anarcat >> <anarcat@anarcat.dyndns.org> wrote: >> >> > On Sun Oct 28, 2001 at 12:23:14PM -0000, Paul Richards wrote: > > [btw, is it me or is this 2 hours *after* your last reply?] > >> >> If libh is an installation tool then it shouldn't be concerned with >> >> package formats. >> > >> > That is the main failed predicate. Libh is not *just* an installation >> > tool. Trivial installation tools are written within libh because it's >> > the only place they can be developped, but they are only consumers, and >> > not part of the library. >> > >> > Some part of the library can be used in installation programs, but that >> > is all. >> > >> > Libh is concerned with package formats because FreeBSD package format >> > needed a rewrite. That is done. >> >> My impression though is that this new package format is totally dependent >> upon the architecture of libh, in that the packages themselves are >> expected to carry large amounts of intelligence in the form of embedded >> tcl. All that libh really does is provide a framework for packages to >> execute their embedded tcl that describes how they should be installed. > > Actually, it's the other way around. Libh architecture is based on the > package format. :) I think someone needs to write a white paper on exactly what libh is and what it's goals are. > But I now understand more clearly the concerns. Indeed, the package > format is arguable. > >> That's nothing like the design Joe and I have been thinking about. > > I didn't know this design included package formats. It doesn't, but libh, as you've said above, is not a generic installer, it is a self-contained environment. I'm sure it's extensible so it can deal with other formats but there's no a-priori design that's taken all that into consideration up front. > I don't feel that design is in "contradiction" with libh's. You only > mention having an API *over* libh and any other package format. Am I > wrong? Couldn't libh package system be used within this new API? Or libh > API changed to fit this new API? It's not. If libh has come up with a new package format then there's no reason that the package API can't support backends for handling that format. Although, the libh package format is different to most in that it is likely to have embedded executable code in it. I'm not sure what impact that would have since it's radically different to any other format that is likely to be supported. My impression is that the libh route means that each package is really it's own installer, and libh just provides a library of the common code needed by each installer. That approach is somewhat unusual. The two projects are complimentary. The work we're looking at doing is not going to deal with libdisk, or installers, or the gui or anything else that sysinstall or the current package tools currently do. We're interested in the low level architecture. To use the existing pkg* tools as an example, we're looking to replace /var/db/pkg with a new storage mechanism and for access to that storage mechanism to be via an API, no direct access. This API should support the development of a whole range of tools that can deal with numerous different package formats and numerous different front ends, including all the current tools that exist. This is a relatively small piece of the complete picture but I think if we do it right it makes the development of everything else a lot more straightforward. libh can continue with everything it's currently developing, including a new package format, but it should use this new API for doing the /var/db/pkg equivalent tasks. > I guess I'm getting confused over your concerns here... > >> One group may want to write a perl intaller, libh would use tcl, another >> group might use C etc. The task that needs to be completed successfully >> with some foresight and planning is the specification of the API, sitting >> down and designing the API before any code is written will result in a >> much more complete an well thought out design. > > Agreed. However, it is too late. Code has already been written. Heck, > even the old package tools count in there. :) It's not too late to design the next package installer, it's obviously too late for existing ones. Paul Richards FreeBSD Services Ltd http://www.freebsd-services.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-binup" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?125480000.1004352801>