Date: Sat, 27 Oct 2001 13:17:27 -0400 From: The Anarcat <anarcat@anarcat.dyndns.org> To: Josef Karthauser <joe@tao.org.uk> Cc: "Simon L. Nielsen" <simon@nitro.dk>, Eric Melville <eric@FreeBSD.org>, binup@FreeBSD.org, libh@FreeBSD.org, Alexander Langer <alex@big.endian.de> Subject: Re: current project steps Message-ID: <20011027131726.A68253@shall.anarcat.dyndns.org> In-Reply-To: <20011026223033.A44573@tao.org.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>
next in thread | previous in thread | raw e-mail | index | archive | help
--2fHTh5uZTiUOsy+g Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri Oct 26, 2001 at 10:30:33PM +0100, Josef Karthauser wrote: > On Fri, Oct 26, 2001 at 05:20:28PM -0400, The Anarcat wrote: > > On Fri Oct 26, 2001 at 10:12:54PM +0100, Josef Karthauser wrote: > > >=20 > > > Does it address the issues that I raised on this list earlier this > > > month, or is it a different kind of thing? > >=20 > > Er... I'm kinda new to the list. Which issues in particular? >=20 > It's a bit brash to tell us what to do if you don't know what we've been > talking about isn't it? ;o). You're right, of course. First off, I'm having problems with the mailing list browser... The "current" html archive contains 4 messages, 2 from me. :) I'll check on the ftp site.=20 [note that I do not talk in the name of the libh project, nor do I want to. I just talk as a developper who happen to work on libh right now. :)] Let's see: On Dim oct 14, 2001 at 05:05:15pm -0700, Eric Melville wrote: >=20 > 1. I've heard speculation of an entirely new package framework, that would > include things such as base system components being installed as > packages. Is this anywhere near reality for 5.0-RELEASE, or should it = be > considered a thought that has past? libh is a entirely new package framework. For a extensive description, see: http://www.freebsd.org/projects/libh.html I think libh will be ready for 5.0. Heck, I'm even coding on -stable, right now! For all I know, it might be ready even before 5.0. > 2. Does it make sense for system components to include other components, = or > would managing dependancies within the updater sound like a better pla= n? I'm not sure I understand here, but what I think is that there should be many simple autonomous packages (sendmail, base, kernel, etc). I'm not fully aware of all the current capabilities of the current libh, since I'm working in another area. Alex should be more aware of that (in CC).=20 But, I know that libh follows the sysinstall2.txt stuff. It's available from OP and from the libh CVS repository and seems to be pretty complete. I also encourage people to take a peek at http://openpackages.org/html/pkg_design.php > In the case of the base system being installed as a set of packages it > sounds like a better plan to manage dependancies, whereas with the > current layout of FreeBSD it may make more sense to go the other way. I personnally think the current layout of /usr/src should be changed. :) Packages in there can install whatever they want, anywhere. There is no record of which files get installed. Heck, we're more severe with ports than with our own tree! We should set the example. :) > 3. A means of classifying packages would be desirable to allow, say, the > installation of a system using postfix instead of sendmail. This would > work along the lines of certain packages being grouped, and then exact= ly > one must be selected. This isn't really a question so much as an extra > point to be considered in the first question. Yes. This is an issue that is not really addressed yet, I think. There is the "pseudo-package" concept, similar to Debian's concept of package role (eg mailserver package abstraction).=20 On Mon Oct 15, 2001 at 02:08:34AM +0100, Josef Karthauser wrote: > Our current package framework is inadequate. It needs to be > reconstructed with a middle layer API to separate the underlying > database representation from the package tools. Unfortuately the > open-packages people don't appear to have realised this. :(. I'm not sure libh adresses this either. But it could! :) Right now, it assumes a certain file hierarchy, using db3, I think. It could probably be possible to extend this to use any other database system. On Mon Oct 15, 2001 at 02:30:57AM +0100, Josef Karthauser wrote: > * Plug new groups of ports in via a plug in module, like the bsdpan > (CPAN) for installed perl modules. Package tools shouldn't be using > /usr/ports/INDEX natively. They should be going through the API so > that other modules can advertise what they're able to install also. > There are loads of things that would benefit from this. Ruby, > Latex, CPAN, etc. libh doesn't address ports issues, in general. On Tue Oct 16, 2001 at 07:00:47PM +0100, Josef Karthauser wrote: >=20 > The key idea is to separate what is currently a bit convoluted. >=20 > There are various core parts of the package system: >=20 > * component installation database. what's installed, where and what > versions. >=20 > 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. Good idea. It should be possible to implement that in libh. Note however, that this is a minor problem, IMHO. The major problem is the lack of upgrade facilities in the current package scheme. Oh, sure, portupgrade can do binary updates, but the system wasn't designed for that, so it's not reliable. In contrast, libh provides smooth binary upgrades, history, and *undos* for package management. > * indexing, package availability and build functionality. >=20 > 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. Of course. This is a problem not addressed by libh, I think. Or at least, not yet. If a database backend abstraction is implemented, however, this would be easy to implement. We have to provide these kind of facilities for packages as well as "ports" (source builds), like debian does.=20 > 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. Agreed. Note that libh packages contain tcl code that is run inside a safe interpreter (that's the basic idea, and what makes it attractive and secure). So this could also be relatively easy to implement too. > It's silly not to be able to directly take advantage of other project's > module repositories. Agreed. As a side note, it might be interesting to provide abstraction for "distfile fetching", eg. cvs vs cvsup vs ftp vs rsync, why not.. > * package install, management tools. >=20 > All of the pkg_* and sysinstall. These are intrinsically separate from > the actual install processes. They should be properly abstracted to > make that clear. Right now, the "package tools" in libh are in the state of "proof of concept", ie very immature. But they are about 20 lines long. ;) Just to demonstrate that the processes is actually taken care of by the library. > 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. Just to make a quick resume..=20 - Libh is a *package* management/access/creation system. - It doesn't handle build procedures.=20 - It currently uses a db backend, but this could be rewritten to use multiple backends. - Libh package management system is really complete and already works fairly well. It provides upgrade facilities, integrity checking, safe installs, etc.=20 > Take a look at the mail archives for this month.=20 Done. I hope I covered the most important issues. > I'd be interested to know whether libh has considered these things. Kind of. Libh original idea was to rewrite the package system to overcome its deficiencies. So it addresses some of these issues, if not all. > I thought that > libh was just a graphical interface that would allow sysinstall and > any package install tools to render to both consoles and x11 with > easy and no code changes. Any am wrong? Yes. Libh is *not* just a graphical interface. Concretly, it features: - 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 I probably get it wrong, but you get the idea... Now I can go back to sleep. :) A. --2fHTh5uZTiUOsy+g 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 iEYEARECAAYFAjva7CYACgkQttcWHAnWiGeaeQCeLTIoI5WPi1sjKWgLJqxmozdl atQAn1l7lVv2J5cwGZfS12MSezVeT2FG =vo9T -----END PGP SIGNATURE----- --2fHTh5uZTiUOsy+g-- 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?20011027131726.A68253>