Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!news.rmit.EDU.AU!news.unimelb.EDU.AU!munnari.OZ.AU!news.hawaii.edu!news.uoregon.edu!arclight.uoregon.edu!enews.sgi.com!news.mathworks.com!news.kei.com!nntp.coast.net!howland.reston.ans.net!nntp.crl.com!reason.cdrom.com!usenet From: "Jordan K. Hubbard" <jkh@FreeBSD.org> Newsgroups: comp.unix.bsd.freebsd.misc Subject: Re: RedHAT RPMs for FreeBSD ? Date: Tue, 11 Jun 1996 20:51:30 -0700 Organization: Walnut Creek CDROM Lines: 84 Message-ID: <31BE3EC2.7DE14518@FreeBSD.org> References: <aak2.834434605@Ra.MsState.Edu> NNTP-Posting-Host: time.cdrom.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mozilla 3.0b4 (X11; I; FreeBSD 2.2-CURRENT i386) To: Atif Ahmad Khan <aak2@Ra.MsState.Edu> CC: ports@freebsd.org Atif Ahmad Khan wrote: > Is there a reason why we shouldn't have RPM as our main > software packaging system ? Yes. We'd simply be trading one set of limitations for another. Let's put it this way, the FreeBSD packaging tools are very powerful and very dangerous - a package can do virtually anything it wants on your system to install itself, up to and including upgrading the operating system to a new release level if it feels like it. The RPMs are much safer, given that they can only do a very limited set of things to install themselves, but can't be used in any of the truly interesting ways one could use a packaging system. I'd like to see, for example, meta-packages which do nothing more than load other packages (so you can have packages like an "X developer's pack" which itself takes up very little space) or be able to have packages which *do* upgrade your operating system if that's their purpose in life (and you authorize them to do so). Like most things in life, the best position to occupy is somewhere in the middle of effective compromise. I'd like to redo the packaging system, yes (this has always been on my wish list), but I'd like to redo it along substantially different lines than either the FreeBSD current packaging scheme or the RH PRMs. Some of the details of what I have in mind, though by no means a complete functional description: 1. Packages are zip files, permitting random access to compressed contents. This is an important advantage over the current scheme (note: there is still some discussion of using zoo instead of zip, but that remains an implementation detail). 2. Anything added to a package file has a default "flavor" which is used to permute its name. In this way, you could have one zip file containing FreeBSD, Linux and NetBSD (for example) distributions of the same product yet happily co-existing. When you extract a "FreeBSD flavored" release, only those files pertaining to FreeBSD are extracted and the names automatically translated back. 3. Each package has a set of known "entry points" which the package- adder will call to have the package add itself. In essence, the package contains its own unpacking instructions. Procedures will be written in secure TCL. 4. The secure TCL API will be augmented to give all file operations an additional level of security. Most notably, all path names will be converted to canonical form and passed through an additional security gate to ensure that no directories or files outside the restricted set (which may be site-specific). In this way, you could for example say "all packages may write on /usr/X11R6/*, /usr/local/* or /etc/shells, but *nothing* else!" This gets around the problem of installing as root and having an errant package clobber another (so far, fully 100% of the problems I've seen have been due to error rather than deliberate attack). 5. Each flavor type will also be able to register its own hooks so that all packages of that flavor automatically inheirit certain functions or variable settings. With some established conventions, it should be possible for a package to refer to system locations and commands symbolically, making a package installation procedure largely common across OS flavors. 6. The security API could be configured to prompt the user interactively every time a package tried something suspect, rather than refusing outright, and it would then be up to the user to make go/no go decisions about what the package would like to do. By forcing the package to do all of its installation actions (including the simple act of adding a file to the system) through TCL, you can gate operations through with a great deal of granularity - something which is simply not possible with a shell script! Needless to say, all of this would be customizable to the nines with hooks everywhere for you to run your own validation routines or create your own package flavors. The biggest hold-up for me so far has simply been lack of time to devote to bringing TCL into the FreeBSD base distribution, where I can rely on it being there for the packaging (and a fair number of other) tools. This is just one of the many areas in which we could use TCL to very good effect! -- - Jordan Hubbard President, FreeBSD Project