Date: Thu, 23 Nov 1995 15:16:12 +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: <199511231516.PAA29078@genesis.atrad.adelaide.edu.au> In-Reply-To: <19246.817134446@time.cdrom.com> from "Jordan K. Hubbard" at Nov 23, 95 05:47:26 am
next in thread | previous in thread | raw e-mail | index | archive | help
Jordan K. Hubbard stands accused of saying:
Argh. Someone upstream just started doing something 8(
> To be honest, I've been thinking about this since long before 2.1 was
> even planned. This stuff is pretty old! :)
Indeed; installers are like that, they grow on you. OK Mr.
Application-management-person, here's your chance to beat a few people
into your development team 8)
> 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.
I think what we're seeing here is reductionism at work. The problems
posed by installation of a number of packages are so diverse that a single
tool aiming to cover them all will expand to resemble a programming
language regardless. Your suggested solution - giving in and starting with
a language isn't invalid, it's just that it (_may_) make the general case
messier.
> > 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.
The ability to _work_ with multiple files is desirable, yes. The
_necessity_ for multiple files is IMHO _not_.
ncftp -c <URL> |tail -c +10000 | tar xf- --fast-read +INSTALL
Will DTRT for an FTP install (yes, it is rude to drop the connection. Go
tell that to Netscape). Yah, it imposes a hard limit of 10K on the +INSTALL
file, it's the concept that's important 8)
You can pull the same trick for floppies (messier if the package
contains multiple tarballs, but that's close to inevitable, and could
alternatively be handled by the multiple-file support).
> 5) Deal with User Preferences
Behavioural constraints? The less behaviour, the fewer constraints 8)
Or are we talking about package-specific user preferences?
> 6) Deal with *other* packages
Aigh! This is an N-complete problem - every package would have to know
about every other package that it might conflict with, or which might
conflict with it. I think not. Certainly, some rudimentary
wolf-goat-lettuce detection would be useful, but otherwise this looks like
a lot of work 8(
> 7) Possibly interact with the user
Agree. Most user interction will be application setup, so we write
application setup programs for all those lazy software authors 8)
> 8) Possibly interact with higher level installation tools.
This is 7) again 8) (or at least we have to _hope_ the user is a higher-level
tool 8)
> 9) Be able to install system distributions
Short of the horific temp-space consumption of the current technique, and the
fact that sysinstall becomes a special case of 5) and 7), that's
pretty straightforward.
> 10) Be able to install packages by a very *wide* variety of means.
Indeed. I'd like to think that we can add web and email package
retrieval to ftp and local media as are currently supported 8)
> 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.
I guess I'm at least partly at a loss as to what you're getting at, as the
current state of the art in installation tools is pretty primitive the
world over.
> 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.
A port would just be a package in a different sort of wrapper.
> dropped) and render it inoperable. There are ways of merging two tcl
> applications (picking unique filenames, rebuilding index files, etc)
I still suspect that this will require a lot of work to carefully
synchronise all possible conflicting items, and possibly give rise to
a whole new crop of gremlins. Then again, I could be wrong 8)
> > > 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'm thinking "I want my disk space for my data. If I want backups,
I'll make them myself, on tape." I'm thinking that this would be a Nice
Toy from the admin-weenie point of view, but the overheads would be
horrific.
Imagine someone tracking -stable, -current, ports and the distfiles.
Naturally, sup would support the 3dfs (if it were implemented properly);
imagine how much space would be consumed.
Imagine the storage required to do a rollback of a major base system
upgrade...
Yes, I understand that you could limit the heep level - but to where?
You'd have to keep at _least_ the most recent 3 versions of something.
Don't get me wrong - I think the idea, and it's fundamental basis, are
quite valid, but I think that implmentation would be problematic, to say
the least.
> > 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
How does this address the problem?
> 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.
You could use this to 'reconstruct' a broken installation. Then again,
the same information could be held in a +LIST file in the current
database format.
> 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.
ls -lR >foo; diff ./ls-lR.yesterday foo 8)
Isn't this doing things the hard way though - should we be looking to
a journalled filesystem instead? (presuming my understanding of JFS is
correct...)
> 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.
A custom-cut X server with support for nothing but VGA mono and Herc mono
would have no need for configuration. You'd only have one colour
model to support too 8)
> 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
I'd as soon not be wedded to anything, but X exists. Its ability to
talk to remote servers would also be nice in the headless case.
> 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?
I guess by that time we'll be able to license Terry's W95 UFS driver
to run the filesystems off... 8)
> > 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? :-)
Yecch. What a hopeless paragraph that was. Sorry; what I wasn't quite
seeing at the time was : the installation should be driven off a _very_
high-level script, run by a mid-level interpreter, talking to one
of a number of backends. I was still thinking X, hence Tk.
Something like :
MENU "mainmenu" "Main Installation Menu" {
ENTRY "Help!" "hotkey=H" { call "help" }
ENTRY "Disk Setup" "hotkey=D" { call "diskmenu" }
ENTRY "Install from...$install_source" "hotkey=I,require=diskok"
{ call "sourcemenu" }
ENTRY "Select distributions" "hotkey=S,require=sourceok" { call "selmenu" }
ENTRY "Perform Installation" "hotkey=P,require=selok" { call "install" }
ENTRY "Cancel Installation" "hotkey=C,Esc" { call "canceleverything" }
}
MESSAGE "help" {
TEXT "Sorry, no help here, sucker!"
}
FUNCTION "canceleverything" {
ASK reponse "Cancel installation and reboot?" "Yes,[NO]"
IF ($response == "Yes") { call "reboot" }
}
And so forth (sic). The idea being that the mid-level interpreter
should handle the flow of execution, and produce the form spec to be
managed by the interface-specifi driver. The menu above, on initial
entry, might generate a spec like :
Menu
Title="Main Installation Menu"
Entry="Help",Hotkey="H",Return=0
Entry="Disk Setup",Hotkey="D",Return=1
Entry="Install from...Nowhere",Disabled
Entry="Select distributions",Disabled
Entry="Perform Installation",Disabled
Entry="Cancel Installation",Hotkey="C",Return=5
Footer="Press F1 for help",Hotkey="F1",return=6
(however it is stored...) This sort of spec could easily be parsed to
produce a menu, form, whatever on a wide variety of displays, completely
independant of the controlling logic.
Before you ask - yes, I'm interested in working on this. Anything for a
real project, instead of running around coming up with half-baked ideas on
my own 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?199511231516.PAA29078>