Date: Mon, 29 Oct 2001 10:13:30 -0500 From: The Anarcat <anarcat@anarcat.dyndns.org> To: Paul Richards <paul@freebsd-services.com> 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: <20011029101329.A94698@shall.anarcat.dyndns.org> In-Reply-To: <125480000.1004352801@lobster.originative.co.uk> References: <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> <125480000.1004352801@lobster.originative.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
--gBBFr7Ir9EOA20Yy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon Oct 29, 2001 at 10:53:21AM -0000, Paul Richards wrote: > --On Sunday, October 28, 2001 18:59:45 -0500 The Anarcat > <anarcat@anarcat.dyndns.org> wrote: >=20 > > 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: > >>=20 > >> > On Sun Oct 28, 2001 at 12:23:14PM -0000, Paul Richards wrote: > >=20 > > [btw, is it me or is this 2 hours *after* your last reply?] > >=20 > >> >> If libh is an installation tool then it shouldn't be concerned with > >> >> package formats. > >> >=20 > >> > 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. > >> >=20 > >> > Some part of the library can be used in installation programs, but t= hat > >> > is all. > >> >=20 > >> > Libh is concerned with package formats because FreeBSD package format > >> > needed a rewrite. That is done.=20 > >>=20 > >> My impression though is that this new package format is totally depend= ent > >> 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. > >=20 > > Actually, it's the other way around. Libh architecture is based on the > > package format. :) >=20 > I think someone needs to write a white paper on exactly what libh is and > what it's goals are. I consider sysinstall2.txt as a good (if not complete) paper on that. It sure needs some fleshing out, but it's a start. > > But I now understand more clearly the concerns. Indeed, the package > > format is arguable. > >=20 > >> That's nothing like the design Joe and I have been thinking about. > >=20 > > I didn't know this design included package formats. >=20 > 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. Indeed. Libh needs to (1) seperate the packages libs from the rest of the libraries more clearly, (2) with a well-documented API. I think part 1 is no problem and in fact is already in place, but part 2 needs some work. > > 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? >=20 > 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. The impact of having tcl code in there is not much more than tools having to link with tcl libraries. I see the executable code simply as a high-level language that is being interpreted. There is such description language in any package format, even our current ones have +CONTENTS files which are getting more and more complex. Might as well have a known language for the meta-language. :) > 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. I think that's a pretty good picture. > That approach is somewhat unusual. Most definitely. > 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 th= at > 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. Agreed. I understand you also have something to present already as such API? > 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. Indeed.=20 > 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. Agreed. I'd be happy to work on this new API and/or libh package system to make them conformant. BTW, I feel I must present apologies to the list and to its members and in particular the participants of this thread for I have been a bit harsh. Sorry if I was a dork. :) A. --gBBFr7Ir9EOA20Yy Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjvdchgACgkQttcWHAnWiGe9uACgmS+UP5NzIaLO3BDeQjxijPiR mr4AoIxKTr7zjL/2o6+1u6FHqMfIVCXm =giDb -----END PGP SIGNATURE----- --gBBFr7Ir9EOA20Yy-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-libh" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011029101329.A94698>