Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 28 Oct 2001 16:06:04 -0500
From:      The Anarcat <anarcat@anarcat.dyndns.org>
To:        Josef Karthauser <joe@tao.org.uk>
Cc:        Jordan Hubbard <jkh@winston.freebsd.org>, Paul Richards <paul@freebsd-services.com>, Alexander Langer <alex@big.endian.de>, "Simon L. Nielsen" <simon@nitro.dk>, Eric Melville <eric@FreeBSD.ORG>, binup@FreeBSD.ORG, libh@FreeBSD.ORG
Subject:   Re: current project steps
Message-ID:  <20011028160603.B71544@shall.anarcat.dyndns.org>
In-Reply-To: <20011028202720.H3223@tao.org.uk>
References:  <joe@tao.org.uk> <2335.1004298360@winston.freebsd.org> <20011028202720.H3223@tao.org.uk>

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

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

On Sun Oct 28, 2001 at 08:27:20PM +0000, Josef Karthauser wrote:
> On Sun, Oct 28, 2001 at 11:46:00AM -0800, Jordan Hubbard wrote:
> > > p.s. libh folken - please don't get the impression that we're
> > > poo-poo'ing what you'd done.  Not at all.  We're all on the same
> > > ultimate side here.
> >=20
> > I don't think anyone has gotten that impression, though I think
> > perhaps a few of us would have been far more gratified by this
> > discussion had you FIRST studied libh and THEN begin discussing what
> > you either wanted or didn't want it to do.  To do it in the reverse
> > order only forces everyone to go through the process of sorting out
> > misunderstandings before any truly constructive dialog can begin.
>=20
> Understood.  In my defence however, libh isn't currently developed
> in an 'in your face' way like most of the tree is (there are a few
> pserver type changes that need to be made first to pull it into
> ncvs/projects).  It's not immediately obvious to people outside of
> the libh project what it is or isn't.=20

There is indeed a lack of documentation in libh that must be corrected.

> It appears from the outside
> to be a project that's been on the boil for a long time without
> affecting the main tree in any significant way.

Libh has been dormant for periods. That doesn't make libh less
interesting to me. :)

> My motivations were spawned by involvement with the development of
> the BSDPAN module for installing perl-cpan modules, with automatic
> registration in the package database. Try installing a perl module
> by hand on -current to see what I mean.  It could do with being
> integrated more completely into the packaging infrastructure.
> Nothing I've seen so far even considers this kind of thing.  In my  =20
> "new world view" the existing ports, live along side a "package"  =20
> module for installing binary upgrades, BSDPAN, rpm and others.  It
> should be extremely easy (via the writing of a single module) to =20
> bolt in a whole new repository of packages and have it just work =20
> with whatever packaging tools, and database backend are currently
> being used.  It seems unwieldly to have so many p5- and ruby- ports
> in existence when by integrating one module each we could make _all_
> of the perl, or ruby modules available in one fell swoop.

You know, this is just the thing libh doesn't and cannot take care of.
The pkg/ports duality. Mostly because, as you said, libh doesn't have a
lot of influence over the main tree, in great part because it *isn't*
into the main tree and built as parts of make worlds, etc. But mostly
because libh is a package system, and /usr/src and /usr/ports are the
packages. ;)

Even having it there as a "switch" could be a great improvement. :)
People could start experimenting with the new package scheme.

This is a project that could be started in parallel with libh:
formalization of the build process, where the build process includes
source access, patching, configuration, building, etc.

The new package system (ie libh package system) is fine, I think. The
hard part is now to integrate packages more nicely into the src trees.
Make /usr/src distros packages. Make /usr/ports be nicer with packages
and, why not, make the actual port skeletons "packages" in a repository.
That would adress the API problems you mentionned about ports not
accessing INDEX directly and things like that..

A.

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

iEYEARECAAYFAjvcczoACgkQttcWHAnWiGfdKgCfakziVE9cpdoMJHXROyVmiJik
CAEAn1gA5aC/24jD8uw4K5pmp1KCu2ey
=wf90
-----END PGP SIGNATURE-----

--FkmkrVfFsRoUs1wW--

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?20011028160603.B71544>