From owner-freebsd-install Wed Feb 11 05:08:15 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id FAA05126 for freebsd-install-outgoing; Wed, 11 Feb 1998 05:08:15 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from fan.net.au (subsonic.fan.net.au [203.20.92.1]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id FAA05120 for ; Wed, 11 Feb 1998 05:08:13 -0800 (PST) (envelope-from q@fan.net.au) Received: from fan.net.au (dialup-nas2-54.gc.fan.net.au [203.23.134.116]) by fan.net.au (8.8.8/8.8.6) with ESMTP id XAA29381 for ; Wed, 11 Feb 1998 23:07:25 +1000 (EST) Message-ID: <34E1A4F4.69E38E6B@fan.net.au> Date: Wed, 11 Feb 1998 23:17:40 +1000 From: Quinton Dolan Organization: Fast Access Network X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 2.2.5-RELEASE i386) MIME-Version: 1.0 To: freebsd-install@FreeBSD.ORG Subject: References to PPP/Slip in the online documentation Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Howdy All, I have a query about the references to PPP/Slip in the online installation instructions. According to the online installion instructions there are three ways of installing over a network. 1) PPP/Slip 2) PLIP 3) Ethernet I have successfully used methods 2 and 3 but I raise the question whether support for PPP/SLIP is even compiled into the kernel on the boot.flp images (at least for 2.2.5-RELEASE anyway) Determined to work out what I was doing wrong I had a poke around inside the MFS and could not locate a ppp0 or tun0 device, but did however find the ppp hard link to sysinstall. But no mention seems to be made of ppp in the installation process anywhere. What am I doing wrong? I realise that installing over PPP would be a slow, painful process. But if it doesn't exist, the documentation should be updated accordingly. Seeya...Q To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 08:19:11 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA15624 for freebsd-install-outgoing; Fri, 13 Feb 1998 08:19:11 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from ifi.uio.no (0@ifi.uio.no [129.240.64.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA15618 for ; Fri, 13 Feb 1998 08:19:04 -0800 (PST) (envelope-from dag-erli@ifi.uio.no) Received: from hrotti.ifi.uio.no (2602@hrotti.ifi.uio.no [129.240.64.15]) by ifi.uio.no (8.8.8/8.8.7/ifi0.2) with ESMTP id RAA13317 for ; Fri, 13 Feb 1998 17:18:31 +0100 (MET) Received: (from dag-erli@localhost) by hrotti.ifi.uio.no ; Fri, 13 Feb 1998 17:18:31 +0100 (MET) To: freebsd-install@FreeBSD.ORG Subject: Questions to the gurus :) Organization: Gutteklubben Terrasse X-url: http://www.ifi.uio.no/~dag-erli/ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit From: dag-erli@ifi.uio.no (Dag-Erling Coidan Smørgrav) Date: 13 Feb 1998 17:18:29 +0100 Message-ID: Lines: 38 X-Mailer: Gnus v5.5/Emacs 19.34 Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK, as some of you may have noticed, I've more or less volunteered to work on a new installation tool. I thought I might benefit from some advice from my elders, so here goes: On the functional side, I'm thinking about a system of .inf files which specify the name, location and size of each distribution, as well as the long description, dependencies etc. (hmmm... perhaps we could even use the pkg format for the distributions...) With some minor work, this could mean that a single boot floppy could be used to install any version of FreeBSD. If the floppy is older than the version you want to install, you can just download the .inf file... I'm also thinking about moving more of the dirty work out of the installer and into backends. I haven't RTFS very closely, but I did notice that ftp is implemented directly into sysinstall. How much space is there available on the boot floppy? Is it enough for fetch? Of course these things are difficult to compute because of crunch... I also have some concerns about the interface. Previous versions of sysinstall are rumoured to work well with screen readers, and that's a feature I feel I should keep, but I have no idea of how these thingumabobs work. Same goes for support for serial consoles of varying arcanity (arcaneness? sp?) - I think sysinstall should support as many terminals as possible (headless How concerned should I be about screen size? Can I safely assume no resizing will take place? Can I safely assume that the screen will be at least 60 columns wide, and at least 15 or 20 lines tall? Is libdialog a big win, or is it OK to code directly against libncurses? More questions will come when I think of them... -- DES (dag-erli@ifi.uio.no) (btw, how d'ya like my new minimalistic sig?) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 09:30:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id JAA23247 for freebsd-install-outgoing; Fri, 13 Feb 1998 09:30:27 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id JAA23242 for ; Fri, 13 Feb 1998 09:30:24 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.8/8.6.9) with ESMTP id JAA07784; Fri, 13 Feb 1998 09:30:20 -0800 (PST) To: dag-erli@ifi.uio.no (Dag-Erling Coidan Sm rgrav) cc: freebsd-install@FreeBSD.ORG Subject: Re: Questions to the gurus :) In-reply-to: Your message of "13 Feb 1998 17:18:29 +0100." Date: Fri, 13 Feb 1998 09:30:20 -0800 Message-ID: <7780.887391020@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On the functional side, I'm thinking about a system of .inf files > which specify the name, location and size of each distribution, as > well as the long description, dependencies etc. (hmmm... perhaps we > could even use the pkg format for the distributions...) With some Sort of - you can't afford the temp space to make them *actual* packages or I'd have done this already. :-) Also, you'd be amazed at how much info is in the already-existing foo.mtree files that accompany every distribution. I've always thought that I should write a function which groked mtree files so that sysinstall could just slurp them in along with the .inf files and derive a complex "packing list" from the info therein. Things like long and short descriptions could go in the existing .inf files = you can have attributes with newlines easily just by saying: long_descr={ this is a long description which will be folded into a single string with newlines by release/sysinstall/attrs.c :) } > I'm also thinking about moving more of the dirty work out of the > installer and into backends. I haven't RTFS very closely, but I did > notice that ftp is implemented directly into sysinstall. How much It used to be, but not anymore. It's actually just calling libftpio for all its services - you'd be reinventing the wheel. That's also the same library fetch() calls, though it implements http xfers internally. Not *too* much call for those in sysinstall (yet), fortunately. > I also have some concerns about the interface. Previous versions of > sysinstall are rumoured to work well with screen readers, and that's a > feature I feel I should keep, but I have no idea of how these > thingumabobs work. I think as long as you move the cursor sanely, you're OK. Max could tell you more, obviously. > Same goes for support for serial consoles of varying arcanity > (arcaneness? sp?) - I think sysinstall should support as many > terminals as possible (headless Just don't break vt100 support or add any evil assumptions about running on a VTY and you should be OK. :) > How concerned should I be about screen size? Can I safely assume no > resizing will take place? Can I safely assume that the screen will be > at least 60 columns wide, and at least 15 or 20 lines tall? Both safe assumptions. > Is libdialog a big win, or is it OK to code directly against > libncurses? Whichever makes you happier - both approaches can be said to suck, just in different ways. :-) Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 11:28:24 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id LAA16093 for freebsd-install-outgoing; Fri, 13 Feb 1998 11:28:24 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id LAA15984 for ; Fri, 13 Feb 1998 11:28:06 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 5063 invoked by uid 1000); 13 Feb 1998 19:32:16 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-020998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Fri, 13 Feb 1998 11:32:16 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: (Dag-Erling Coidan=?us-ascii?Q?_Sm=F8rgrav?=) Subject: RE: Questions to the gurus :) Cc: freebsd-install@FreeBSD.ORG Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 13-Feb-98 Dag-Erling Coidan Smørgrav wrote: > OK, as some of you may have noticed, I've more or less volunteered to > work on a new installation tool. I thought I might benefit from some > advice from my elders, so here goes: What is so wrong with the existing tool, that we have to re-write the whole thing? I must have missed something. > On the functional side, I'm thinking about a system of .inf files > which specify the name, location and size of each distribution, as > well as the long description, dependencies etc. (hmmm... perhaps we > could even use the pkg format for the distributions...) With some > minor work, this could mean that a single boot floppy could be used to > install any version of FreeBSD. If the floppy is older than the > version you want to install, you can just download the .inf file... Last I checked one boot floppy does it all alreeady. No? > I'm also thinking about moving more of the dirty work out of the > installer and into backends. I haven't RTFS very closely, but I did > notice that ftp is implemented directly into sysinstall. How much > space is there available on the boot floppy? Is it enough for fetch? > Of course these things are difficult to compute because of crunch... > > I also have some concerns about the interface. Previous versions of > sysinstall are rumoured to work well with screen readers, and that's a > feature I feel I should keep, but I have no idea of how these > thingumabobs work. > > Same goes for support for serial consoles of varying arcanity > (arcaneness? sp?) - I think sysinstall should support as many > terminals as possible (headless > > How concerned should I be about screen size? Can I safely assume no > resizing will take place? Can I safely assume that the screen will be > at least 60 columns wide, and at least 15 or 20 lines tall? > > Is libdialog a big win, or is it OK to code directly against > libncurses? Since virtually all dialogues are of a given style and format, one would think that having a library will help. Personally, I do not mind the existing look and feel at all. I just finished installing Win95 and Caldera Linux, plus being very familiar with Debian Linux, I find sysinstall to be superior to all these in structure and flow and totally acceptable in look and feel. > > More questions will come when I think of them... > > -- > DES (dag-erli@ifi.uio.no) (btw, how d'ya like my new minimalistic sig?) > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-install" in the body of the message ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.708.7858 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 15:34:47 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA03847 for freebsd-install-outgoing; Fri, 13 Feb 1998 15:34:47 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA03835 for ; Fri, 13 Feb 1998 15:34:44 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA05166; Fri, 13 Feb 1998 15:33:54 -0800 (PST) Message-Id: <199802132333.PAA05166@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: dag-erli@ifi.uio.no (Dag-Erling Coidan Sm rgrav) cc: freebsd-install@FreeBSD.ORG Subject: Re: Questions to the gurus :) In-reply-to: Your message of "13 Feb 1998 17:18:29 +0100." Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Date: Fri, 13 Feb 1998 15:33:53 -0800 From: Mike Smith Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id PAA03837 Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On the functional side, I'm thinking about a system of .inf files > which specify the name, location and size of each distribution, as > well as the long description, dependencies etc. (hmmm... perhaps we > could even use the pkg format for the distributions...) With some > minor work, this could mean that a single boot floppy could be used to > install any version of FreeBSD. If the floppy is older than the > version you want to install, you can just download the .inf file... Sure. But you're not going far enough. I'm not really ready to release this, but holding it back longer will not help the cause any more than putting it out for wider scrutiny. Please find attached an early draft of a document describing parts of the new package scheme. Some relevant issues that may not be obvious from the document: - Packages are shipped in Zip-format files. We have a contributed library that allows us to work on these directly, without needing to unpack the entire package somewhere first. - The base operating system will be packaged using this scheme. - There will be a database backend responsible for tracking package(s) owning file(s).a - The install scripts packaged with the base OS components will be responsible for installing the components. Non-component setup will still have to be handled by the installer. > Same goes for support for serial consoles of varying arcanity > (arcaneness? sp?) - I think sysinstall should support as many > terminals as possible (headless We have a couple of UI options currently under consideration; Borland's TurboVision is one, there is another, hopefully friendlier, UI under development by another contributor. We expect to see an early cut of this in a week or so. There has been not inconsiderable discussion about using a diagrammatic rather than procedural path through the installer, somewhat akin to the way that InstallShield behaves. A document describing this is currently outstanding. > How concerned should I be about screen size? Can I safely assume no > resizing will take place? Can I safely assume that the screen will be > at least 60 columns wide, and at least 15 or 20 lines tall? Expect that 80x24 is the limit. > Is libdialog a big win, or is it OK to code directly against > libncurses? Avoid interminging UI code and backend code. > More questions will come when I think of them... If you want something really helpful, very important, and likely to result in lots of discussion and a strong ongoing commitment, might I humbly suggest that you install everything from a recent 3.0 snapshot on a fresh machine (or some other equivalent technique), and start dividing the base operating system into categories? By this I mean make a list of individual *files* that comprise each category. I would suggest the following categories: - base Base system components required for operation - devel Compiler, linker, headers, static libraries, etc. Subdivide into devel-base, devel-c++, devel-objc, etc. - text Text processing tools (*roff, etc) - manpages Subdivide into manpages-base, manpages-devel, etc. as starters. I'm sure you can come up with more. There are also obviously dependancies involved too. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 15:54:29 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA08016 for freebsd-install-outgoing; Fri, 13 Feb 1998 15:54:29 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA08001 for ; Fri, 13 Feb 1998 15:54:27 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id PAA05277 for ; Fri, 13 Feb 1998 15:54:11 -0800 (PST) Message-Id: <199802132354.PAA05277@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: install@FreeBSD.ORG Subject: New package scheme, early draft Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 15:54:11 -0800 From: Mike Smith Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Apolgies for omitting this from the previous message. New Software Packaging Tools for FreeBSD ====================================================================== (c) Michael Smith and contributors 1997, 1998 What's wrong with the current tools? ------------------------------------ - The current packaging tools have no sense of continuity, ie. - there is no understanding that foo-1.2 is an upgrade to foo-1.1 - installing foo-1.2 over the top of foo-1.1 does not transfer dependancies from the old version. - It is not possible to apply updates to a package; packages can only be installed wholesale. - The use of tar/gzip requires an expensive unpacking stage. - There is no mechanism for reverting to a previous version of a package. - The information kept about files installed from a package is not enough to verify the state of a package. - A file or directory cannot belong to more than one package. - Various combinations of the above make it impossible to use the package tools for distributing components of the base system. What will the new tools do? --------------------------- - Continuity will be maintained across versions of a package: - it will only be possible to have one version of a package installed at a given time. - upgrading/downgrading a package will transfer dependancies. - Packages will be identified using an extended naming scheme that allows updates to be applied to a package. - Packages will use the Zip format, allowing direct installation from the package file rather than using a staging area. - A comprehensive database will be kept regarding the files belonging to package(s), including all pertinent data about the file (eg. ownership, permissions, checksum (if appropriate), package(s) claiming ownership, etc). - Packages will be able to be up/downgraded at will. How new packages will be built. ------------------------------- A package will consist of a single Zip file containing the package script and optional data files. The package script will be called PACKAGE, and be contained at the top level of the Zip file. Other files will be organised in subdirectories to suit the package script. Package flavours ---------------- A package may contain one of: - A complete software component, allowing installation of some version on a virgin system. - A component upgrade, allowing the upgrading of a given range of previous versions to a new version. - A delta, adding extra functionality or fixes to an existing installed component. The package script. ------------------- All operations on the package are controlled by the package script. The script is a plain text file, divided into sections as detailed below. Each section is formatted as : { } where is one of the standard operations INFO, INSTALL, REMOVE, VERIFY, or a package-specific operation. The INFO section provides general information about the package. It is processed every time the package information is read. The INSTALL and REMOVE sections contain procedures for performing the installation/removal of the package. The VERIFY section may contain extra code for performing verification of the installation status of the package. Normal verification consists of performing MD5 signature and permissions checks of installed files. Other tests may look for data files, running processes, etc. The package script is parsed and executed by a secure Tcl interpreter. Many standard Tcl commands and variables are also available (xref command list). The package system also exports a number of variables (xref variable list). In addition, the following commands are available, Unless otherwise stated, commands may appear in any order, and are processed in the order they appear. INFO section ------------ NAME Sets the package name to be operated on by this section. If this name does not match that of the Zip file, an error may be generated. In the case of a package containing a delta, nominates the package to which the delta will be applied. This name is used by the REQUIRE VERSION and REQUIRE DELTA commands (see below) to locate the "current" package. VERSION . Sets the major/minor version number for the package to assume following a successful installation. DELTA [...] Sets the delta name(s) to be added/removed following a successful installation/removal. CANONICALNAME Packages will often contain third-party software with completely different naming conventions. This command supplies a canonical name for the name-major.minor+delta combination that results from a successful installation of the contents of the package. INSTALL section --------------- REQUIRE PACKAGE Produces an error if evaluates false. In addition, the package(s) whose presence contributes to satisfying the expression are listed in $pkg_info(package:required), and if the installation completes successfully the requirement will be permanently recorded. (Feature: recursive fetch/install of required-but-not-present packages/deltas) REQUIRE VERSION (XXX should allow expression?) Produces an error if the current package (as specified in the PACKAGE command above) does not meet . This command is normally used in packages containing deltas (nominating the version(s) to which the delta may be applied) or upgrades from earlier versions of the package. REQUIRE DELTA Produces an error if the current package (as specified in the PACKAGE command above) does not meet . This command is normally used in packages containing deltas to state the prerequisite delta set. The delta(s) whose presence contributes to satisfying the expression are listed in $pkg_info(delta:required), and if the installation of the delta completes successfully the requirement will be permanently recorded. REQUIRE USER REQUIRE GROUP The user/group specified must be present for the installation to complete. (Feature: automatic adding of user/group. Preserve real UID/GID in variables.) EXCLUDE PACKAGE Produces an error if evaluates true. In addition, a record is kept of the exclusion condition, and no package/delta may be subsequently added which meets the exclusion condition. (Feature: automatic removal of excluded packages) EXCLUDE DELTA Produces an error if the current package (as specified in the PACKAGE command above) meets . This command is normally used in packages containing deltas to state the set of deltas which are known to not coexist. If the delta is added successfully, a record is kept of the expression and no package may be subsequently added which meets the condition. USE PACKAGE If a package matching is present, it will be listed in $pkg_info(use), and if the installation completes successfully this usage will be upgraded to a requirement. (Feature: automatic fetch/install of uses-but-not-present packages/deltas, with user prompting configurable) REPLACE PACKAGE If a package matching is present, the user may be prompted to indicate that the offending package should be removed first. The string may be supplied as justification for this. EXEC Executes the program located in the package at . If the current security model prohibits execution of script-supplied programs, an error will be generated. SOURCE [] The script located in the package at is executed in another Tcl interpreter with security set to . If this level is incompatible with the current security model, an error will be generated. If no level is specified, the current level is maintained. INSTALL [@] INSTALL [] Installs files from the within the package archive into in the filesystem. If @ is supplied, the file at that location in the package is consulted for a list of files to be installed. If is supplied, the files listed are installed. If neither is supplied, all files under are installed. In all cases, every file installed is recorded. If an error occurs installing a file, all installed files are removed and an error is returned. During an upgrade installation, files need not be present in the package if the version from the previous version(s) are suitable. In this case, they should still be passed to the INSTALL command, which will note that the file is not supplied but already present. This will prevent the file in question from being removed as obsolete. The argument should be an absolute path; it will normally be one of the paths from $pkg_info(path:*), see below. Other paths may be specified, but the security model in force may not allow installation outside the nominated areas. ATTRIBUTE ADD [@] ATTRIBUTE ADD [] ATTRIBUTE ADD [] Adds an attribute to file(s). Attributes control how files are installed and recorded. The destination path should match that supplied when the file is installed. If @ is supplied, the file at that location is consulted for a list of files to which the attribute will be applied. If is supplied, the attribute is applied to the listed files. If a single path is supplied, and it refers to a relative source path within the Zip archive, and the Zip archive is available, the names of all files under that path are used. Currently supported attributes are: CONTENTS_VARY The file's contents may vary over the installed lifetime of the package. As such, keeping a checksum of the file is not useful. INHERIT_FILE The file is not included as part of the package, but may be produced by the application and should be considered as belonging to the package. Implies CONTENTS_VARY. (XXX more here!) PRESERVE Normally when an upgrade from a previous version is being performed, the files from the previous version are removed. This command causes all files matching from the previous version to be preserved. This directive is most suitable for preservation of configuration files when upgrading from a compatible previous version. (XXX should this prevent the file being overwritten by an INSTALL?) PRESERVE ALL This command is normally used in an upgrade situation where the wholesale removal of all files associated with the previous version is not desired. It should normally be avoided in preference to supplying the files in question to the INSTALL command. KEEP Specifies that the file(s) at/under should be preserved by the installation proecess for later use in other sections (which may be invoked when the Zip file is not present). Files retained by KEEP should be stored in the same place the PACKAGE file is kept. REMOVE section -------------- (XXX functionality to stop a running daemon etc. before removing) VERIFY section -------------- (XXX functionality to verify that a daemon etc. is running) General commands ---------------- These commands may be used in any section. MATCH PACKAGE Returns a list of packages currently installed which match . PKG_NAME PKG_MAJOR PKG_MINOR PKG_DELTAS Return various components of a package name Variable list ------------- These variables are defined by the package system, and may be consulted by the package script. pkg_info This array contains fields describing the package. package:name Contains the name component of the current package, if known. package:required Lists full package identifiers for packages that have been established as prerequisites for the current package. delta:required Lists the deltas which have been established as prerequisites for the current package. security:policy (readonly) Names the current security policy. security:exec (readonly) Boolean indicating whether the current security policy will allow the EXEC command. security:source Boolean indicating whether the current security policy will allow the SOURCE command. security:paths Lists the path prefix components under which files may be installed; if this list is empty, files may be installed anywhere. path:prefix The standard installation prefix; where files go by default. path:x11prefix The prefix for X11-related files. What's missing? --------------- - Text-file editing primitives (eg. replace PREFIX) Expressions and names. ---------------------- Package identifiers. A given package in a given state is described thus: -. where is an alpha token identifying the package. Only one package with this name may be present in the system at a given time. is the major version number for the package. This number is incremented when the package undergoes a change which is likely to render it incompatible with previous versions. is the minor version number for the package. This number is incremented when the package changes but the change is not likely to result in incompatabilities. is a list of entries, each formatted as +, which identify deltas which have been applied to the package. Package Deltas. In order to allow minor changes to be made to a package without requring a change in version numbers, as well as to allow customisations of a package, "deltas" are supported. A delta applies to an existing package (possibly to a range of versions), and may replace or alter files within the package. (Feature: the package tools may elect to refuse to apply a delta which alters files previously altered by another delta. The aim here is to reduce the likelihood of two deltas produced in igorance of one another being able to interfere.) Package Specification. A package specification is a wildcard expression intended to match against package identifiers. All fields must be present, and matching occurs separately for each field. A package identifier matches if all fields match the specification. Glob-style string patterns are supported here. (xref Tcl 'string match') , These fields may contain '*' (matching any version), or a numeric value preceeded by >, >=, =, <= or <, matching if the ident being considered has a field numerically greater, greater or equal, equal, less or equal or less than the value supplied. The = prefix may be omitted for simplicity. Items in the delta list may be prefixed with +, indicating that the named delta is required for a match, or !, indicating that the named delta must not be present for a match. Commands using package specifications may treat the results of a match as a logical value (eg. in an expression) or as a list of matching packages. Specifications may be grouped to form expressions. In an expression, specifications are considered to evaluate 'true' if they match one or more packages. Operators supported are '&&' (logical and) and '||' (logical or). Precedence must be established using parentheses, an expression may not contain more than one operator. (XXX someone write a better expression parser?) When evaluating expressions, the full set of matched items is retained and may be used by the command evaluating the expression. Expressions are fully, not lazily, evaluated. This is a glob-style file match. It returns a list of files matching the expression. The leading path may be explicitly matched (if the spec begins with a /), otherwise the command using the spec may only match the trailing component, depending on context. This is a package-internal relative path. It may be evaluated within the Zip file, or within some storage area containing files extracted from the Zip file by a KEEP command. The database. ------------- Everything known about files installed from packages, package requirements and exclusions, etc. is stored in the package management database. Package records define packages that have been installed. A package record matches a given name-major.minor tuple. The package record contains (XXX enumerate fields). Delta records are attached to package records. Each delta record contains details of the delta (XXX enumerate fields). Delta records are sorted by order of application. File records contain information pertaining to files under control of the package system. Files may be claimed by more than one package, so the file:package association is kept separately from the file record. (XXX enumerate fields, comment on attributes) The filestore and backing out. ------------------------------ XXX Elaborate on moving of files from old packages to the store, and resurrection of old versions from the store when new versions installed. Also mention purging of old versions from the store. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 16:29:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA16106 for freebsd-install-outgoing; Fri, 13 Feb 1998 16:29:54 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from pscwa.psca.com (popmail.pscwa.psca.com [199.99.162.253]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id QAA16101 for ; Fri, 13 Feb 1998 16:29:52 -0800 (PST) (envelope-from iyengar@pscwa.psca.com) Received: from vulcan by pscwa.psca.com (NX5.67f2/NX3.0M, PSCWA update 950701) id AA01695; Fri, 13 Feb 98 16:29:05 -0800 Message-Id: <9802140029.AA01695@pscwa.psca.com> Received: by vulcan.pscwa.psca.com (NX5.67g/NX3.0X) id AA02669; Fri, 13 Feb 98 16:29:04 -0800 Content-Type: text/plain Mime-Version: 1.0 (NeXT Mail 4.2mach v148) In-Reply-To: <199802132354.PAA05277@dingo.cdrom.com> X-Nextstep-Mailer: Mail 4.2mach (Enhance 2.0b5) Received: by NeXT.Mailer (1.148) From: Manu Iyengar Date: Fri, 13 Feb 98 16:29:02 -0800 To: Mike Smith Subject: Re: New package scheme, early draft Cc: install@FreeBSD.ORG Reply-To: m@pscwa.psca.com References: <199802132354.PAA05277@dingo.cdrom.com> X-Subliminal-Message: Have you paid The Bill? Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You guys might consider taking a look at the way NEXTSTEP & OPENSTEP handle packages. They provide some good paradigms/ideas to build upon, and make it really trivial to install stuff...Cheers, - m@psca.com >From the keyboard of Mike Smith on Fri, 13 Feb 1998: > Apolgies for omitting this from the previous message. > > New Software Packaging Tools for FreeBSD > ====================================================================== > (c) Michael Smith and contributors 1997, 1998 > > > What's wrong with the current tools? > ------------------------------------ > > - The current packaging tools have no sense of continuity, ie. > - there is no understanding that foo-1.2 is an upgrade to foo-1.1 > - installing foo-1.2 over the top of foo-1.1 does not transfer > dependancies from the old version. > > - It is not possible to apply updates to a package; packages can only > be installed wholesale. > > - The use of tar/gzip requires an expensive unpacking stage. > > - There is no mechanism for reverting to a previous version of a > package. > > - The information kept about files installed from a package is > not enough to verify the state of a package. > > - A file or directory cannot belong to more than one package. > > - Various combinations of the above make it impossible to use the > package tools for distributing components of the base system. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 16:41:16 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id QAA18931 for freebsd-install-outgoing; Fri, 13 Feb 1998 16:41:16 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id QAA18897 for ; Fri, 13 Feb 1998 16:41:08 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id QAA05546; Fri, 13 Feb 1998 16:39:50 -0800 (PST) Message-Id: <199802140039.QAA05546@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: m@pscwa.psca.com cc: Mike Smith , install@FreeBSD.ORG Subject: Re: New package scheme, early draft In-reply-to: Your message of "Fri, 13 Feb 1998 16:29:02 PST." <9802140029.AA01695@pscwa.psca.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 16:39:50 -0800 From: Mike Smith Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > You guys might consider taking a look at the way NEXTSTEP & OPENSTEP handle > packages. They provide some good paradigms/ideas to build upon, and make it > really trivial to install stuff...Cheers, Thanks, I think there's a copy of NS around 3.something in the office. The SGI 'inst' facility has some nice paradigms too, but I don't have an SGI to play with it on. 8) I'm completely shameless when it comes to adopting good ideas, and very open (even at this point) to suggestions. Not to mention offers of development assistance. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 17:14:07 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA25947 for freebsd-install-outgoing; Fri, 13 Feb 1998 17:14:07 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA25903 for ; Fri, 13 Feb 1998 17:13:58 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 10247 invoked by uid 1000); 14 Feb 1998 01:20:41 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-020998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802132333.PAA05166@dingo.cdrom.com> Date: Fri, 13 Feb 1998 17:20:41 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: Questions to the gurus :) Cc: freebsd-install@FreeBSD.ORG, (Dag-Erling Coidan Sm rgrav) Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Another, important feature: Allow for templates. Example; At Atlas, we build two types of FreeBSD configurations: - A server, which has not GUI, a particular kernel configuration, particular disk layout and partitioning, particular networking options, and a particular ports mix. - A Workstation which uses a different kernel configuration, different disk layout, different ports mix, differnt netwoking options, etc. Currently, the system builder must know and understand the differences, and follow a paper guide as to which has what. since the builders are both human and not hackers, they make occasional maistakes. If we could, easily create a ``configuration'' that includes a kernel, fdisk data, disklabel data, fstab data, internet data, etc. and if the installer software could allow me to install ``Authentication Server'' vs. ``GUI Workstation'' vs. ``Standard BSd Workstation'', etc. It would be very helpful. The key here is the ability to create: a. Configuration template which contains answers to all the current questions. b. Multiple boot floppies, one per configuration c. All of these without tearing into the Makefiles for the release. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.708.7858 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 17:16:23 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26193 for freebsd-install-outgoing; Fri, 13 Feb 1998 17:16:23 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id RAA26186 for ; Fri, 13 Feb 1998 17:16:17 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 10271 invoked by uid 1000); 14 Feb 1998 01:23:10 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-020998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802132354.PAA05277@dingo.cdrom.com> Date: Fri, 13 Feb 1998 17:23:10 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: RE: New package scheme, early draft Cc: install@FreeBSD.ORG Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Perfect! On most of my systems the staging space is not a problem, but I can see how that can be important. An idea for a package is to use ar(1) for the pacage. It is a well understood, inhenerntly Unix facility. A bit unusual, but why not? On 13-Feb-98 Mike Smith wrote: > > Apolgies for omitting this from the previous message. > > New Software Packaging Tools for FreeBSD > ====================================================================== > (c) Michael Smith and contributors 1997, 1998 > > > What's wrong with the current tools? > ------------------------------------ > > - The current packaging tools have no sense of continuity, ie. > - there is no understanding that foo-1.2 is an upgrade to foo-1.1 > - installing foo-1.2 over the top of foo-1.1 does not transfer > dependancies from the old version. > > - It is not possible to apply updates to a package; packages can only > be installed wholesale. > > - The use of tar/gzip requires an expensive unpacking stage. > > - There is no mechanism for reverting to a previous version of a > package. > > - The information kept about files installed from a package is > not enough to verify the state of a package. > > - A file or directory cannot belong to more than one package. > > - Various combinations of the above make it impossible to use the > package tools for distributing components of the base system. > > What will the new tools do? > --------------------------- > > - Continuity will be maintained across versions of a package: > - it will only be possible to have one version of a package > installed at a given time. > - upgrading/downgrading a package will transfer dependancies. > > - Packages will be identified using an extended naming scheme that > allows updates to be applied to a package. > > - Packages will use the Zip format, allowing direct installation from > the package file rather than using a staging area. > > - A comprehensive database will be kept regarding the files belonging > to package(s), including all pertinent data about the file > (eg. ownership, permissions, checksum (if appropriate), package(s) > claiming ownership, etc). > > - Packages will be able to be up/downgraded at will. > > How new packages will be built. > ------------------------------- > > A package will consist of a single Zip file containing the package > script and optional data files. The package script will be called > PACKAGE, and be contained at the top level of the Zip file. Other > files will be organised in subdirectories to suit the package script. > > Package flavours > ---------------- > > A package may contain one of: > > - A complete software component, allowing installation of some > version on a virgin system. > - A component upgrade, allowing the upgrading of a given range of > previous versions to a new version. > - A delta, adding extra functionality or fixes to an existing > installed component. > > > The package script. > ------------------- > > All operations on the package are controlled by the package script. > The script is a plain text file, divided into sections as detailed > below. > > Each section is formatted as : > > { > > } > > where is one of the standard operations INFO, INSTALL, > REMOVE, VERIFY, or a package-specific operation. > > The INFO section provides general information about the package. It is > processed every time the package information is read. > > The INSTALL and REMOVE sections contain procedures for performing the > installation/removal of the package. > > The VERIFY section may contain extra code for performing verification > of the installation status of the package. Normal verification > consists of performing MD5 signature and permissions checks of > installed files. Other tests may look for data files, running > processes, etc. > > The package script is parsed and executed by a secure Tcl interpreter. > Many standard Tcl commands and variables are also available (xref > command list). The package system also exports a number of variables > (xref variable list). > > In addition, the following commands are available, Unless otherwise > stated, commands may appear in any order, and are processed in the > order they appear. > > INFO section > ------------ > > NAME > > Sets the package name to be operated on by this section. If > this name does not match that of the Zip file, an error may be > generated. In the case of a package containing a delta, > nominates the package to which the delta will be applied. > This name is used by the REQUIRE VERSION and REQUIRE DELTA > commands (see below) to locate the "current" package. > > > VERSION . > > Sets the major/minor version number for the package to assume > following a successful installation. > > DELTA [...] > > Sets the delta name(s) to be added/removed following a > successful installation/removal. > > > CANONICALNAME > > Packages will often contain third-party software with > completely different naming conventions. This command > supplies a canonical name for the name-major.minor+delta > combination that results from a successful installation of the > contents of the package. > > INSTALL section > --------------- > > REQUIRE PACKAGE > > Produces an error if evaluates > false. In addition, the package(s) whose presence contributes > to satisfying the expression are listed in > $pkg_info(package:required), and if the installation completes > successfully the requirement will be permanently recorded. > > (Feature: recursive fetch/install of required-but-not-present > packages/deltas) > > > REQUIRE VERSION (XXX should allow expression?) > > Produces an error if the current package (as specified in the > PACKAGE command above) does not meet . This > command is normally used in packages containing deltas > (nominating the version(s) to which the delta may be applied) > or upgrades from earlier versions of the package. > > > REQUIRE DELTA > > Produces an error if the current package (as specified in the > PACKAGE command above) does not meet . > This command is normally used in packages containing deltas to > state the prerequisite delta set. The delta(s) whose presence > contributes to satisfying the expression are listed in > $pkg_info(delta:required), and if the installation of the > delta completes successfully the requirement will be > permanently recorded. > > > REQUIRE USER > REQUIRE GROUP > > The user/group specified must be present for the installation to > complete. > > (Feature: automatic adding of user/group. Preserve real UID/GID > in variables.) > > > EXCLUDE PACKAGE > > Produces an error if evaluates true. > In addition, a record is kept of the exclusion condition, and > no package/delta may be subsequently added which meets the > exclusion condition. > > (Feature: automatic removal of excluded packages) > > > EXCLUDE DELTA > > Produces an error if the current package (as specified in the > PACKAGE command above) meets . This command > is normally used in packages containing deltas to state the > set of deltas which are known to not coexist. If the delta is > added successfully, a record is kept of the expression and no > package may be subsequently added which meets the condition. > > > USE PACKAGE > > If a package matching is present, it will be > listed in $pkg_info(use), and if the installation completes > successfully this usage will be upgraded to a requirement. > > (Feature: automatic fetch/install of uses-but-not-present > packages/deltas, with user prompting configurable) > > > REPLACE PACKAGE > > If a package matching is present, the user may > be prompted to indicate that the offending package should be > removed first. The string may be supplied as > justification for this. > > > EXEC > > Executes the program located in the package at > . If the current security model prohibits > execution of script-supplied programs, an error will be > generated. > > > SOURCE [] > > The script located in the package at is > executed in another Tcl interpreter with security set to > . If this level is incompatible with the > current security model, an error will be generated. If no > level is specified, the current level is maintained. > > > INSTALL [@] > INSTALL [] > > Installs files from the within the package > archive into in the filesystem. If > @ is supplied, the file at that location in the > package is consulted for a list of files to be installed. If > is supplied, the files listed are > installed. If neither is supplied, all files under > are installed. > > In all cases, every file installed is recorded. If an error > occurs installing a file, all installed files are removed and > an error is returned. > > During an upgrade installation, files need not be present in > the package if the version from the previous version(s) are > suitable. In this case, they should still be passed to the > INSTALL command, which will note that the file is not supplied > but already present. This will prevent the file in question > from being removed as obsolete. > > The argument should be an absolute path; it > will normally be one of the paths from $pkg_info(path:*), see > below. Other paths may be specified, but the security model > in force may not allow installation outside the nominated areas. > > ATTRIBUTE ADD [@] > ATTRIBUTE ADD [] > ATTRIBUTE ADD [] > > Adds an attribute to file(s). Attributes control how files > are installed and recorded. The destination path should match > that supplied when the file is installed. If @ is > supplied, the file at that location is consulted for a list of > files to which the attribute will be applied. If > is supplied, the attribute is applied to the > listed files. If a single path is supplied, and it refers to > a relative source path within the Zip archive, and the Zip > archive is available, the names of all files under that path > are used. > > Currently supported attributes are: > > CONTENTS_VARY The file's contents may vary over the > installed lifetime of the package. As > such, keeping a checksum of the file > is not useful. > > INHERIT_FILE The file is not included as part of > the package, but may be produced by > the application and should be > considered as belonging to the > package. Implies CONTENTS_VARY. > > (XXX more here!) > > > PRESERVE > > Normally when an upgrade from a previous version is being > performed, the files from the previous version are removed. > This command causes all files matching from > the previous version to be preserved. > > This directive is most suitable for preservation of > configuration files when upgrading from a compatible previous > version. > > (XXX should this prevent the file being overwritten by an > INSTALL?) > > PRESERVE ALL > > This command is normally used in an upgrade situation where > the wholesale removal of all files associated with the > previous version is not desired. It should normally be > avoided in preference to supplying the files in question to > the INSTALL command. > > KEEP > > Specifies that the file(s) at/under should be > preserved by the installation proecess for later use in other > sections (which may be invoked when the Zip file is not present). > > Files retained by KEEP should be stored in the same place the > PACKAGE file is kept. > > REMOVE section > -------------- > > (XXX functionality to stop a running daemon etc. before removing) > > VERIFY section > -------------- > > (XXX functionality to verify that a daemon etc. is running) > > General commands > ---------------- > > These commands may be used in any section. > > MATCH PACKAGE > > Returns a list of packages currently installed which match > . > > > PKG_NAME > PKG_MAJOR > PKG_MINOR > PKG_DELTAS > > Return various components of a package name > > > Variable list > ------------- > > These variables are defined by the package system, and may be > consulted by the package script. > > pkg_info > > This array contains fields describing the package. > > package:name > > Contains the name component of the current package, if > known. > > package:required > > Lists full package identifiers for packages that have > been established as prerequisites for the current > package. > > delta:required > > Lists the deltas which have been established as > prerequisites for the current package. > > security:policy (readonly) > > Names the current security policy. > > security:exec (readonly) > > Boolean indicating whether the current security policy > will allow the EXEC command. > > security:source > > Boolean indicating whether the current security policy > will allow the SOURCE command. > > security:paths > > Lists the path prefix components under which files may > be installed; if this list is empty, files may be > installed anywhere. > > path:prefix > > The standard installation prefix; where files go by > default. > > path:x11prefix > > The prefix for X11-related files. > > What's missing? > --------------- > > - Text-file editing primitives (eg. replace PREFIX) > > > Expressions and names. > ---------------------- > > Package identifiers. > > A given package in a given state is described thus: > > -. > > where > > is an alpha token identifying the package. Only one > package with this name may be present in the system at > a given time. > is the major version number for the package. This > number is incremented when the package undergoes a > change which is likely to render it incompatible with > previous versions. > is the minor version number for the package. This > number is incremented when the package changes but the > change is not likely to result in incompatabilities. > is a list of entries, each formatted as +, > which identify deltas which have been applied to the > package. > > Package Deltas. > > In order to allow minor changes to be made to a package without > requring a change in version numbers, as well as to allow > customisations of a package, "deltas" are supported. > > A delta applies to an existing package (possibly to a range of > versions), and may replace or alter files within the package. > > (Feature: the package tools may elect to refuse to apply a delta which > alters files previously altered by another delta. The aim > here is to reduce the likelihood of two deltas produced in > igorance of one another being able to interfere.) > > Package Specification. > > A package specification is a wildcard expression intended to match > against package identifiers. All fields must be present, and matching > occurs separately for each field. A package identifier matches if all > fields match the specification. > > Glob-style string patterns are supported here. (xref > Tcl 'string match') > > , These fields may contain '*' (matching any version), > or a numeric value preceeded by >, >=, =, <= or <, > matching if the ident being considered has a field > numerically greater, greater or equal, equal, less or > equal or less than the value supplied. The = prefix > may be omitted for simplicity. > Items in the delta list may be prefixed with +, > indicating that the named delta is required for a > match, or !, indicating that the named delta must not > be present for a match. > > Commands using package specifications may treat the results of a match > as a logical value (eg. in an expression) or as a list of matching > packages. > > > > > Specifications may be grouped to form expressions. In an > expression, specifications are considered to evaluate 'true' if they > match one or more packages. > > Operators supported are '&&' (logical and) and '||' (logical or). > Precedence must be established using parentheses, an expression may > not contain more than one operator. (XXX someone write a better > expression parser?) > > When evaluating expressions, the full set of matched items is > retained and may be used by the command evaluating the expression. > Expressions are fully, not lazily, evaluated. > > > > This is a glob-style file match. It returns a list of files matching > the expression. The leading path may be explicitly matched (if the > spec begins with a /), otherwise the command using the spec may only > match the trailing component, depending on context. > > > > This is a package-internal relative path. It may be evaluated within > the Zip file, or within some storage area containing files extracted > from the Zip file by a KEEP command. > > > The database. > ------------- > > Everything known about files installed from packages, package > requirements and exclusions, etc. is stored in the package management > database. > > Package records define packages that have been installed. A package > record matches a given name-major.minor tuple. The package record > contains (XXX enumerate fields). > > Delta records are attached to package records. Each delta record > contains details of the delta (XXX enumerate fields). Delta records > are sorted by order of application. > > File records contain information pertaining to files under control of > the package system. Files may be claimed by more than one package, so > the file:package association is kept separately from the file record. > (XXX enumerate fields, comment on attributes) > > The filestore and backing out. > ------------------------------ > > XXX Elaborate on moving of files from old packages to the store, and > resurrection of old versions from the store when new versions > installed. Also mention purging of old versions from the store. > > > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-install" in the body of the message ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.708.7858 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 17:21:26 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA26794 for freebsd-install-outgoing; Fri, 13 Feb 1998 17:21:26 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA26788 for ; Fri, 13 Feb 1998 17:21:24 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA05777; Fri, 13 Feb 1998 17:19:26 -0800 (PST) Message-Id: <199802140119.RAA05777@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , freebsd-install@FreeBSD.ORG, dag-erli@ifi.uio.no (Dag-Erling Coidan Sm rgrav) Subject: Re: Questions to the gurus :) In-reply-to: Your message of "Fri, 13 Feb 1998 17:20:41 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 17:19:25 -0800 From: Mike Smith Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If we could, easily create a ``configuration'' that includes a kernel, > fdisk data, disklabel data, fstab data, internet data, etc. and if the > installer software could allow me to install ``Authentication Server'' vs. > ``GUI Workstation'' vs. ``Standard BSd Workstation'', etc. It would be > very helpful. You can do this already. See /usr/src/release/sysinstall/install.cfg -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 17:25:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id RAA27130 for freebsd-install-outgoing; Fri, 13 Feb 1998 17:25:01 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from dingo.cdrom.com (dingo.cdrom.com [204.216.28.145]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id RAA27122 for ; Fri, 13 Feb 1998 17:25:00 -0800 (PST) (envelope-from mike@dingo.cdrom.com) Received: from dingo.cdrom.com (localhost [127.0.0.1]) by dingo.cdrom.com (8.8.8/8.8.5) with ESMTP id RAA05820; Fri, 13 Feb 1998 17:23:23 -0800 (PST) Message-Id: <199802140123.RAA05820@dingo.cdrom.com> X-Mailer: exmh version 2.0zeta 7/24/97 To: shimon@simon-shapiro.org cc: Mike Smith , install@FreeBSD.ORG Subject: Re: New package scheme, early draft In-reply-to: Your message of "Fri, 13 Feb 1998 17:23:10 PST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 13 Feb 1998 17:23:23 -0800 From: Mike Smith Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Perfect! On most of my systems the staging space is not a problem, but I > can see how that can be important. 8) > An idea for a package is to use ar(1) for the pacage. It is a well > understood, inhenerntly Unix facility. A bit unusual, but why not? Because Zip supports compression, and we have an already-donated zipfile manipulation library. -- \\ Sometimes you're ahead, \\ Mike Smith \\ sometimes you're behind. \\ mike@smith.net.au \\ The race is long, and in the \\ msmith@freebsd.org \\ end it's only with yourself. \\ msmith@cdrom.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 19:49:59 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA20954 for freebsd-install-outgoing; Fri, 13 Feb 1998 19:49:59 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA20947 for ; Fri, 13 Feb 1998 19:49:54 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 12298 invoked by uid 1000); 14 Feb 1998 03:56:45 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-020998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802140119.RAA05777@dingo.cdrom.com> Date: Fri, 13 Feb 1998 19:56:45 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: Questions to the gurus :) Cc: freebsd-install@FreeBSD.ORG, (Dag-Erling Coidan Sm rgrav) Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14-Feb-98 Mike Smith wrote: >> If we could, easily create a ``configuration'' that includes a kernel, >> fdisk data, disklabel data, fstab data, internet data, etc. and if the >> installer software could allow me to install ``Authentication Server'' >> vs. >> ``GUI Workstation'' vs. ``Standard BSd Workstation'', etc. It would be >> very helpful. > > You can do this already. See /usr/src/release/sysinstall/install.cfg Great and perfect!, but that implies running make release several times. Does it not? Also, how do we tell it which kernel to use? Which kernel to install as /kernel on the installed system? Don't misunderstand me. What we have appears very good. Let's make sure this functionality does not go away, but expands to answer questions as above. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.708.7858 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 19:51:27 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA21097 for freebsd-install-outgoing; Fri, 13 Feb 1998 19:51:27 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fxp0.Simon-Shapiro.ORG [206.190.148.34]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id TAA21092 for ; Fri, 13 Feb 1998 19:51:23 -0800 (PST) (envelope-from shimon@sendero-fxp0.simon-shapiro.org) Received: (qmail 12333 invoked by uid 1000); 14 Feb 1998 03:58:14 -0000 Message-ID: X-Mailer: XFMail 1.3-alpha-020998 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <199802140123.RAA05820@dingo.cdrom.com> Date: Fri, 13 Feb 1998 19:58:14 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: Mike Smith Subject: Re: New package scheme, early draft Cc: install@FreeBSD.ORG Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 14-Feb-98 Mike Smith wrote: >> Perfect! On most of my systems the staging space is not a problem, but >> I >> can see how that can be important. > > 8) > >> An idea for a package is to use ar(1) for the pacage. It is a well >> understood, inhenerntly Unix facility. A bit unusual, but why not? > > Because Zip supports compression, and we have an already-donated > zipfile manipulation library. As long as the resulting file is not called TOOSHORT.EXE :-) > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-install" in the body of the message ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.708.7858 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message From owner-freebsd-install Fri Feb 13 23:42:00 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA13660 for freebsd-install-outgoing; Fri, 13 Feb 1998 23:42:00 -0800 (PST) (envelope-from owner-freebsd-install@FreeBSD.ORG) Received: from superior.mooseriver.com (dynamic63.pm03.san-mateo.best.com [205.149.174.191]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id XAA13637 for ; Fri, 13 Feb 1998 23:41:57 -0800 (PST) (envelope-from jgrosch@superior.mooseriver.com) Received: (from jgrosch@localhost) by superior.mooseriver.com (8.8.8/8.8.5) id XAA25699; Fri, 13 Feb 1998 23:41:56 -0800 (PST) Message-ID: <19980213234155.48595@mooseriver.com> Date: Fri, 13 Feb 1998 23:41:55 -0800 From: Josef Grosch To: install@FreeBSD.ORG Subject: [jgrosch@mooseriver.com: Re: New package scheme, early draft] Reply-To: jgrosch@superior.mooseriver.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 Sender: owner-freebsd-install@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----Forwarded message from Josef Grosch ----- Message-ID: <19980213234029.02950@mooseriver.com> Date: Fri, 13 Feb 1998 23:40:29 -0800 From: Josef Grosch To: Mike Smith Subject: Re: New package scheme, early draft Reply-To: jgrosch@MooseRiver.com References: <199802132354.PAA05277@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.79 In-Reply-To: <199802132354.PAA05277@dingo.cdrom.com>; from Mike Smith on Fri, Feb 13, 1998 at 03:54:11PM -0800 On Fri, Feb 13, 1998 at 03:54:11PM -0800, Mike Smith wrote: > > Apolgies for omitting this from the previous message. > > New Software Packaging Tools for FreeBSD > ====================================================================== > (c) Michael Smith and contributors 1997, 1998 > > > What's wrong with the current tools? > ------------------------------------ > > - The current packaging tools have no sense of continuity, ie. > - there is no understanding that foo-1.2 is an upgrade to foo-1.1 > - installing foo-1.2 over the top of foo-1.1 does not transfer > dependancies from the old version. > > - It is not possible to apply updates to a package; packages can only > be installed wholesale. > > - The use of tar/gzip requires an expensive unpacking stage. > > - There is no mechanism for reverting to a previous version of a > package. > > - The information kept about files installed from a package is > not enough to verify the state of a package. > > - A file or directory cannot belong to more than one package. > > - Various combinations of the above make it impossible to use the > package tools for distributing components of the base system. > [ DELETED ] This is very good. Two comments; 1) The package system needs a concept of how much disk space the package will unpack into and how much space is currently availabe. 2) Look at HP's package on how to handle dependency. Josef -- Josef Grosch | Another day closer to a | FreeBSD 2.2.5 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses -----End of forwarded message----- -- Josef Grosch | Another day closer to a | FreeBSD 2.2.5 jgrosch@MooseRiver.com | Micro$oft free world | UNIX for the masses To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-install" in the body of the message