Date: Tue, 16 Oct 2001 19:00:47 +0100 From: Josef Karthauser <joe@tao.org.uk> To: Eric Melville <eric@FreeBSD.org> Cc: Murray Stokely <murray@FreeBSD.org>, binup@FreeBSD.org Subject: Re: design issues Message-ID: <20011016190047.H83396@tao.org.uk> In-Reply-To: <20011016103434.D4211@FreeBSD.org>; from eric@FreeBSD.org on Tue, Oct 16, 2001 at 10:34:34AM -0700 References: <20011014170515.B39749@FreeBSD.org> <20011014180507.D2654@windriver.com> <20011015020834.Y31066@tao.org.uk> <20011014181709.E2654@windriver.com> <20011016103434.D4211@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--iY5udFbGw2SsPZe4 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 16, 2001 at 10:34:34AM -0700, Eric Melville wrote: > > Do you mean something as simple as just moving some of the > > functionality of pkg_add into a libpkg so that other applications can > > use it? That's a weekend project at most and something I've > > definitely wanted for a long time. sysinstall would be an obvious > > consumer of this library, since sysinstall uses cpio to deal with > > packages and I've seen packages that pkg_add likes but sysinstall > > doesn't like. >=20 > I tend to forget that sysinstall installs packages because I never use it, > so disregard the prior comment about not seeing a gain from a libpkg. I'd > still like more details about extending the package framework, however. The key idea is to separate what is currently a bit convoluted. There are various core parts of the package system: * component installation database. what's installed, where and what versions. This is currently in /var/db/pkg. It should be possible to use other backends. It should be possible to drop a 'plug in' module in place to store this information in whatever way the admin wants. Why not a central SQL server containing info on all the servers/workstations in the cluster, for instance. * indexing, package availability and build functionality. At the moment /usr/ports/INDEX is the only way to know what can be installed. this should be abstracted. it should be possible to write, for instance, a CPAN module that connects to a CPAN mirror and abstracts a complete list of what modules are available and have the pkg_install tools automatically know about these too. If we get this right it would be possible to add whole chunks of new ports automatically by writing an interface module to the relevant system. Of the top of my head, ruby, perl, latex would benefit from these straight away. We already have a perl module in the tree that does the right thing (tm) when you install a perl module by hand. It creates a /var/db/pkg entry and allows the user to pkg_delete it afterward. This could be more tightly integrated. It's silly not to be able to directly take advantage of other project's module repositories. * package install, management tools. All of the pkg_* and sysinstall. These are intrinsically separate from the actual install processes. They should be properly abstracted to make that clear. * /usr/ports/XXXX The /usr/ports/ system is just one mechanism for installing packages. The BSDPAN module is another (perldoc BSDPAN). At the moment the lines between all of these parts of the packaging system are blurred. By contructing a proper API they can correctly defined, and allow us to have a far more powerful packaging system in the process. Joe --iY5udFbGw2SsPZe4 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 iEYEARECAAYFAjvMdc8ACgkQXVIcjOaxUBblPgCgyd7BGjUw1Gv0bgtE1iNLbNSY p7QAoOJBB/XKjpHmhCCNgqrhqvgXVlOg =9j4n -----END PGP SIGNATURE----- --iY5udFbGw2SsPZe4-- 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?20011016190047.H83396>