Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Oct 2001 13:26:40 -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:  <20011028132639.A71003@shall.anarcat.dyndns.org>
In-Reply-To: <361480000.1004271794@lobster.originative.co.uk>
References:  <20011020202153.A76835@FreeBSD.org> <20011026135930.03D1637B406@hub.freebsd.org> <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>

next in thread | previous in thread | raw e-mail | index | archive | help

--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun Oct 28, 2001 at 12:23:14PM -0000, Paul Richards wrote:
>=20
> If libh is an installation tool then it shouldn't be concerned with packa=
ge
> 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.=20

> It should only need to call the API that knows how to install
> packages.

This is the way it's done.

Take a look at the file release/pkgtools/pkg_install.tcl, its a good
example.

> Those packages need not necessarily be in FreeBSD format (either
> old or new) but could be in any number of different formats and pulled fr=
om
> any number of different repositories.

Unfortunatly, libh' libpkg only understands its own format now, but it
should be possible to implement other backends.

> The API would take care of the
> particalar package format and register all the relevant information into
> the  chosen datastore, but consumers of the API would know nothing about
> any of this.

Yes. Of course, this hasn't been extensively architectured in libh,
because the first part consisted into writing a proper set of procedures
and a basic API to interface the new package system.

> To do that in libh you'd basically have to implement the sort of API we've
> been talking about here, but the API should be designed so that it is also
> pluggable into other applications.

No problem. Let's not just re-invent the wheel. There is already an API,
and it should be pretty pluggable in other apps and unpluggable from
libh. :)

> It makes more sense to develop it as a
> separate project, with libh as a consumer, than to develop it as part of
> libh, so that there is no risk of it having any dependencies on libh or
> it's design being overly influenced by the specific requirements of libh.

I don't think anyone sees a problem with that, apart from the fact that
noone has taken up any work yet. My fears are to see golden mouth come
in and tear libh apart to take the pkg API away and then let it rot. :)

libh without the pkg api is not much, arguably. If you re-read the mail
I wrote, you'll note that about 2/3 or 3/4 or the api is pkg oriented
(file, database, pkg, etc). There is only libhdisk that might belong to
the installer part, and it is bound to go as FreeBSD finds a decent disk
library (libdisk has to go):

A quote:

- Database access
- File access abstraction (urls, etc)
- Package stream access
- Libdisk wrapper
- package library
- tcl/c/c++ interface
- seemless C/C++/TCL GUI (Tvision/Qt) library

what would not be part of a seperate project here? The GUI and libhdisk.
libhdisk is a trivial wrapper and the GUI is optional.

I feel like saying: "people, stop complaining and code!" But I don't
want to upset anyone. But I sure feel that a lot of people have a lot
of criticism wrt libh or OP. These criticism should be oriented more
towards changing the existing API (if necessary) than creating a whole
new one.

I also feel that a few people here didn't read my answer properly nor
did they really take time to look at what libh was doing.

Sorry if I'm a bit harsh too.

A.

--vtzGhvizbBRQ85DL
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

iEYEARECAAYFAjvcTd4ACgkQttcWHAnWiGcfjACeJIheKlPz/SCkDR/ITMWBv9a6
0wUAniAObMAU/ijSwgbU3L+3BBAqQb3L
=1RwU
-----END PGP SIGNATURE-----

--vtzGhvizbBRQ85DL--

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?20011028132639.A71003>