Date: Thu, 23 Nov 1995 07:20:56 +0000 () From: Michael Smith <msmith@atrad.adelaide.edu.au> To: jkh@time.cdrom.com (Jordan K. Hubbard) Cc: msmith@atrad.adelaide.edu.au, asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND Message-ID: <199511230720.HAA28188@genesis.atrad.adelaide.edu.au> In-Reply-To: <3052.817058108@time.cdrom.com> from "Jordan K. Hubbard" at Nov 22, 95 08:35:08 am
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying: > OK, here's my take on what needs to be done: Argh! Jordan's finished 2.1 and needs a bigger mountain! 8) Seriously though, I guess if we want to do the thousand-pound package strategy, this isn't such a bad scenario. > 1. The existing package format needs to die for several reasons, the foremost > being: > > o The "plist" syntax loses, lacks conditionals, is arcane, > does not handle checksum verification, preserves insufficient > information for proper deletion, sucks, is evil, gag, retch, > puke. But it's simple. And the only one of the items above (it's two, really, if you count verification) that it loses on is the explicit list of files, sizes and times required for safe package deletions. > o Having the packages be gzip'd tarballs does not allow sufficient > random access and requires hateful amounts of temporary storage. > This is why there are "distributions" and there are "packages" > and the twain have never met. That bites, because they're both > different solutions for the same problem. True. We can wrap a package/distribution in another tarfile, and extend/ refrob/whatever the plist++ syntax to allow multiple tarballs inside the wrapper. You could then have safe multiple prefixes, and use tar -xf --fast-read --to-stdout tarball | (cd $prefix; tar -xzf -) to rip the tarball straight into its destination. We don't have perms files (ever seen a SCO package?), so this is potentially risky if anyone's silly enough to have users online at the time 8) > o Too many other reasons to mention. Everything under > /usr/src/usr.sbin/pkg_install needs to be toasted with a > flamethrower, the remains of the disk it was on bombarded with > hard gamma radiation, crushed into tiny fragments and dumped like > confetti over the north sea. This code is *begging* to die. You're too harsh. It makes for wonderful reading, and I've won several "you think _your_ toy language can be hard to read?" for K&R with that as a feature piece. > For one thing, the PLIST needs to go away and be replaced by a genuine > interpreted language. I'm not saying forth, I'm not even saying TCL Woooah mamma. Hold it _right_ there. Before we go writing InstallShield for FreeBSD (now _there's_ code that begs to die), let's have a look at what a package tool needs to do : 1) Add packages. 2) Remove packages. 3) Verify that a package is complete and correct. 4) Provide details on a package. -*-*-*- 4) You may want to know almost everything about a package : what it is, where it goes, what it requires, how big it is, who wrapped it, etc. 3) When the package is installed, a record of _everything_ that the package contained (files, sizes, timestamps, possibly config entries) should be made, so that it is possible to see what's been changed since the package was installed. Verifying a package should also mark the database for the package, to indicate that it was verified OK (or not). 2) Everything that comprises the package should be removed (optionally not if it was changed). Optionally, everything depending on the package should also die. 1) This is where the fun always is. Firstly, I can't see the real difference between a package and a port, apart from the process of producing the installed components from the supplied raw materials. I don't think that there _should_ be any difference, from the user's point of view. (Special cases such as interactive ports aside.) A package may have prerequisites, which should be installed recursively first. The files for a package should be extracted, avoiding overwriting anything, unless told to, and the placement of the files should be documented. Up to here, there's nothing requiring any scripting language, and we've covered a large proportion of the package population already. As far as I can see, the only thing that requires any "intelligence" in the whole process is frobbing system config files to (un)support the package in question. Given that most of these files are line- or field- based, adding a few relatively straightforward primitives (add this line/field, remove any lines/fields that look like this, etc) will bring our coverage close to 100%. Mind you, that's much less _fun_ 8) > (though it sounds promising), maybe even my little C interpreter since > I got it going again - it does a lot of things that TCL doesn't do, > like compile and run on a virtual machine. Complete sideline - where can I get this? > In any case, the important > thing is to make plists much more flexible, eliminate the idea of > external require/install/deinstall scripts and use the language > instead (so that you can do the equivalent of safe-tcl and declare > certain operations off-limits for untrusted packages). The only 'require' that should be valid is the presence/nonpresence of other packages. > We can also bolt in concepts like MD5 conflict detection and such a > lot more easily with a system like this. I think a PGP (or similar) -based package signature is _essential_. > Secondly, the package format itself needs to support the idea of > extracting just the bootstrap segment or description info from the > package (quickly) and allowing the bootstrap to unpack the package > directly in-place (or through the 3DFS library) without going through > an intermediate directory. > > Many of these component technologies could be worked on separately by > different people (in fact, I almost recommend it) and then assembled > into a complete system. The double-wrapped tarball would seem to do this ideally. Please do _not_ think about a proprietary file format - I spent too long unwrapping the stupid RedHat stuff just to get at their _source_code_ to think that it's a good idea. Inside the 'outer wrapper', you can put the script(s), icons, and one or more data-filled compressed tarballs containing components of the package. You could also reference tarballs _outside_ the wrapper, and thus hit the distfile concept on the head. > 2. A very simple 3D filesystem library. Neat. Lots of work, but possibly worth the effort. I can see us fielding a lot of questions from Lusers who have installed seventeen copies of emacs and filled up their "attic" filesystem though, and making the database smart enough to deal with damage caused by "2D" users/tools might be more work than the implementation itself. > This could be done by any reasonably competent ncurses hacker. That > would not, unfortunately, include me! :-( Death to character-mode interfaces! If people want text screens, they can have commandline-driven tools 8) We have an X server that will run on 16-colour VGA, on Herc-style mono cards, and who knows what else. This leaves users of async terminals and CGA cards out in the cold; both of these sorts would probably be quite happy with straightforward commandline tools. > about ncurses to actually draw the objects. This needs to be > abstracted *anyway*, actually, so that we can do this under X too > when the time comes. The time to start is _now_. > We also need a specification format for the various GUI screens, since > nobody wants to hack that stuff out in raw C if they can help it. > Does this mean libforms? Something else? Tk. Not because it's the best, or the easiest, or anything other than that it's _common_. On top of it, a set of form components and a form manager in whatever language wins (your Forth 'setup', Jordan?), that eats form specifications and generates appropriate form layouts : Title "Network Configuration" Field "Hostname", STRING, REQUIRED Field "IP Address", IPADDR, REQUIRED Field "Netmask", HEX(0-0xffffffff), REQUIRED Field "Nameserver", IPADDR, OPTIONAL Field "Gateway", IPADDR, OPTIONAL You could probably write a form manager for almost any interface that would swallow this, actually, my bias against text interfaces aside 8) > Jordan -- ]] Mike Smith, Software Engineer msmith@atrad.adelaide.edu.au [[ ]] Genesis Software genesis@atrad.adelaide.edu.au [[ ]] High-speed data acquisition and (GSM mobile) 041-122-496 [[ ]] realtime instrument control (ph/fax) +61-8-267-3039 [[ ]] "Who does BSD?" "We do Chucky, we do." [[
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199511230720.HAA28188>