Date: Thu, 23 Nov 1995 05:47:26 -0800 From: "Jordan K. Hubbard" <jkh@time.cdrom.com> To: Michael Smith <msmith@atrad.adelaide.edu.au> Cc: asami@cs.berkeley.edu, ports@FreeBSD.ORG Subject: Re: Proposal 3: Non-executable file in *_DEPEND Message-ID: <19246.817134446@time.cdrom.com> In-Reply-To: Your message of "Thu, 23 Nov 1995 07:20:56 GMT." <199511230720.HAA28188@genesis.atrad.adelaide.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. To be honest, I've been thinking about this since long before 2.1 was even planned. This stuff is pretty old! :) > 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. Yes, the plist format is simple, which is why it evolved that way, but it has deeper problems. Consider, for example, the twistedness of @exec and @unexec, or the necessity for @dirrm, or the way that prefixes are handled, or even the gross specialized expansion of `%<n>' directives to make up for the lack of any environment variable handling. I could go on. The number of special case hacks and kludges that were added after the initial plist syntax was defined is living proof, IMNSHO, that the original specification syntax was flawed. > 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 -) I think it's simply time to go the DEC route, where you have multiple files comprising a package. Probably one or more foo.tgz files and a foo.inf file for each package. Yeah, it's messier and it knocks the paradigm of "one file per package" for a loop, but it make things a LOT easier across all the various media I'll need to support - think everything from floppies to FTP. > 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. 5) Deal with User Preferences 6) Deal with *other* packages 7) Possibly interact with the user 8) Possibly interact with higher level installation tools. 9) Be able to install system distributions 10) Be able to install packages by a very *wide* variety of means. It's a more complex problem that *just* what pkg_install provides. pkg_install is actually insufficient for the task in many respects and I wouldn't model the next generation tool after it. > 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 agree that a port install should still mimic a package install, however that's a different area of the problem. I'm just looking at merging packages and distributions right now. > Up to here, there's nothing requiring any scripting language, and we've > covered a large proportion of the package population already. You need the scripting language to talk to the user (conditionally), be more clever about wedging a package into place (there are many scenarios where a stupid install, like zircon, will just smash another port (like that tkcvs thing we used to have but seem to have wisely dropped) and render it inoperable. There are ways of merging two tcl applications (picking unique filenames, rebuilding index files, etc) but our current "blind, dumb robot" - the plist parser - doesn't know how to do any of those things and it wouldn't even be easy to train it. > [My C interpreter] > Complete sideline - where can I get this? Let me just finish my current code review on it and I'll release it again. In its previous incarnation, it was an X widget placement language (kind of like Tk and TCL cemented together) and I've always wanted to prise the functionality apart. > > 2. A very simple 3D filesystem library. > > Neat. Lots of work, but possibly worth the effort. Well, think more than packages - think "system upgrades" and I think you'll see why the chronological store becomes a lot more important. > 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. To be honest, I was thinking of doing a terrible thing (assuming I can get away with it): I was going to hack tar and cpio to recognise 3D file systems and let you specify "tag" information and such so that the extraction follows the 3DFS API. E.g.: tar -xvzf foo.tar --3dfstag MYREL_2_1 -C /my3dfs Could be made to DTRT. Other damage with 2D tools, well, I think we could at the very least have an options for: 1. Checking tree sanity, and if a checksum fails or a delta is found missing, report it and optionally try and fetch it from a known-good source. 2. Reconstructing the "visible" tree from scratch using some event tag. Both of these features would be really cool anyway and would deal with the long-standing problem of knowing whether that /usr/src you're looking at is *really* a good one, or if someone (maybe even sup) has spammed it. > 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. Now now, you forget one thing: I don't *like* writing command line interfaces! :-) Of course, I guess I could always expand the "script" mechanism from 2.1 to let the user type the script interactively at the keyboard.. :-) Still, it's really too early to declare the death of character mode interfaces. Yes, I'm an X hacker and I much prefer hacking on X interfaces, but an all-singing, all-dancing system written in Tk would, I believe, still be just a *bit* before its time. We'd still have all these people with perfectly reasonable systems but totally unable to get past the evil and scarey xf86config program and considerably frustrated by the exercise. For those all-too-numerous people, we need to use ncurses. And c'mon - you can still do some interesting things from ncurses, and it keeps us reasonably honest about not getting too wedded to X. Not as a first cut, but I'd like to eventually see a DOS character graphics module (as the ncurses and X11 interfaces would also be drop-in modules) written so that someone could write a custom version of the installer to run entirely under DOS. Why not? You've got full access to the BIOS there, and if you're trying to set up some sort of UMSDOS style FreeBSD installation (something we've always wanted to be able to do) why not do it right under DOS? And please don't say "DOS graphics" - I'd like an interface that responds to keystrokes in the user's lifetime.. :) > 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 : Oh dear, are we back to the Tk vs Ctk wars then? :-) Jordan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19246.817134446>