Date: Fri, 26 Oct 2001 16:59:52 -0400 From: The Anarcat <anarcat@anarcat.dyndns.org> To: "Simon L. Nielsen" <simon@nitro.dk> Cc: Eric Melville <eric@FreeBSD.org>, binup@FreeBSD.org, libh@FreeBSD.org Subject: Re: current project steps Message-ID: <20011026165952.D11804@shall.anarcat.dyndns.org> In-Reply-To: <20011026135930.03D1637B406@hub.freebsd.org> References: <20011020202153.A76835@FreeBSD.org> <20011026135930.03D1637B406@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--/unnNtmY43mpUSKx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, On Fri Oct 26, 2001 at 03:58:51PM +0200, Simon L. Nielsen wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 > On Sunday 21 October 2001 05:21, Eric Melville wrote: >=20 > > 1. Extend package framework with middle layer API and system packages > To do this we should properly document what the current package system ca= n=20 > do, and what would be nice to change when it's is being rewritten anyway. just FYI, the package library *is* being re-written, within the libh project, and I think it's doing fine. It just needs a couple more developpers. :) I think what binup should concentrate on is the client/server paradigm because the package system is already under way. We sure need coders for it though... > > 2. Work concept of system packages into the FreeBSD tree > Could this maybe be done with the current makefiles? I don't know enough= =20 > about the FreeBSD build system to know that, but from what I have seen it= =20 > looks like the makefiles contains much of the information needed (program= =20 > names, program locations and so on). I'm not sure about that. A given "install" might put more stuff that we expect. We probably need pkg-plists. Even if that sucks. > > 3. Create library with basic portupgrade functionality and network prot= ocol libh. a libh package install is already an "upgrade". See the libh mailing list for Alex's first successful upgrade of xv (I think). :) > > 4. Write applications that use this library to update the system > > Well it will take a while to do the first to steps, so we should properly= =20 > worry about these later. FWIW, I'm currently writing a fdisk/disklabel-type editor using libh (I'm at the last phase, edition of mount points, newfs options, etc). Heck, we already have boot floppies! Believe me, we just need to work on libh a bit more. What's heavily missing is documentation, but the developpment framework is there. > > upgrade it with binup, and then return using the source tree without > > hassle. This is not trivial, but assumedly could be accomplished by > > using the mk makefiles to register system components in the package > > database as it installs them. > Exactly what kinds of problems to you see if the base system is using=20 > packages? I would guess when installing from source the only difference i= s=20 > that you compile the packages yourself? Of course to find a way to give t= he=20 > self compiled version package version numbers might be a bit tricky It's the same problem that cd /usr/ports/foo/bar ; make install not detecting a previous version. In the ports system, the package is created *after* install, not before. It would probably be possible to create packages from /usr/obj (or equivalent), and then install these, but the fundamental problem is that: cd /foo/bar ; make install is more efficient than cd /foo/bar ; make package ; pkg_add bar.tgz > > Additionally, after the client library is completed, I would like to ma= ke > > usage of a binup server a valid means of installation for libh. > > Hmm, I have been reading the document Jordan wrote about libh=20 > (http://www.freebsd.org/projects/libh.html), but I don't really know exac= tly=20 > what have been done in libh and how much overlap there is between libh an= d=20 > the reworking of the pacakge system.. libh *is* the rework of the package system, for what I know...=20 What it doesn't cover is the conversion of /usr/src (and /usr/ports!) to use a package scheme. BTW, I think this is necessary, not only for the binup project, but for system integrity. Suppose you have an evil binary "foo" that we discovered a nasty security hole in, and that we disconnected "foo" from the worl build. Suppose you cvsup && make world. The binary is probably going to be left there. :) A. --/unnNtmY43mpUSKx 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 iEYEARECAAYFAjvZzscACgkQttcWHAnWiGfHYQCgo1ZejoqRrKOBjmEFcE8vMTba klAAoIJvWs77d5RmLD+rB6RT/aAiK8+p =bLBQ -----END PGP SIGNATURE----- --/unnNtmY43mpUSKx-- 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?20011026165952.D11804>