X-Git-Url: https://pd.if.org/git/?p=zpackage;a=blobdiff_plain;f=Commands;h=1525edc88072788302be6f86695d8bdb672449c8;hp=04c5b61794d7360e672cd037e1d2c4ce53d2c927;hb=HEAD;hpb=4a3b13f88e29f90e3ea28935bb261fdb1a26b7ed

diff --git a/Commands b/Commands
index 04c5b61..1525edc 100644
--- a/Commands
+++ b/Commands
@@ -1,6 +1,90 @@
+Cut it down: You're:
+manipulating a package file
+	add a file
+	remove a file
+	tag a file
+	tag the package
+	setting package metadata
+	setting file metadata
+installing a package
+	options: include/exclude tagsets/files, package root, package database
+uninstalling a package
+	options: preserve files/tags
+updating a package
+manipulating the local database
+	same a package file, but more obvious that you have to specify
+	a specific package
+showing local database information
+showing package file information
+manipulating remote repositories
+
 zpm: always a shell script, that way it can source config files and export environment
 variables for sub-programs
 
+Good to have a program to check if a package exists.  That is, would
+zpm install do anything, at least notionally.
+
+Three basic modes
+
+1: working on the local database and manipulating packages
+This is where 'install' 'update' 'remove' etc are done.
+Additionally, this is where notes, bug reports, repo
+control, and so forth are done.  Since this is the most
+common mode, these commands shouldn't need a prefix or
+something saying we're dealing with the local package DB.
+
+2: working on a package file.
+This is where building a new package, adding files, and otherwise
+dealing with package metadata happens
+
+3: working on a repository of package files
+
+Since 2 and 3 are the less common operations, they can have
+more verbose syntax, also, 2 "expects" a package file, so
+require an option to force using the local DB, and 3 expects
+needs repos, perhaps force not using local DB
+Difference between working on a repository, and manipulating
+repository info for the local or other DB
+And 1 expects the local db, so option to specify package file.
+
+-f for package file?  or -p? and for cat 2, take as argument if
+not specified?  perhaps an option to construct?  probably
+not, have a program to construct if needed.
+
+Need a way to specify a non-default local database location,
+/var/lib/zpm/local.zpm by default
+
+For 2: zpm pkg
+For 3: zpm repo
+
+Conceivably for 2: 'zpm -f <pkgfile>', since if it's not the
+local package database, you'll have to specify the package file
+
+install: will search the repos for the most recent package.
+of install a from a package file given with -f.
+
+so zpm install -f 'pkgfile' will install all packages in that file
+zpm install -f pkgfile package will install just the named package
+zpm install -f pkfile package package2 will installed both packages
+zpm install -f pkgfile -V 1.2 will install version 1.2 of all packages
+that have a version 1.2
+zpm install -f pkgfile foo-1.2 will install version 1.2 of package foo
+
+zpm install foo will install the most up to date foo from the
+repos
+
+zpm install foo-1.2 install version 1.2.  how to distinguish
+between versions and package names with hyphens?  Use @?
+
+Package filters: Version, release, name, min/max version, min/max release
+Package tags?
+
+File filters: Get everything, except exclude by tag, which will
+exclude every file with the tag.  Can reverse sense, and get
+nothing, except what's in tag. +tag will add a tag to the set,
+-tag will remove it.  'tag' sets the tag list
+
+
 Environment Variables
 ---------------------
 
@@ -10,15 +94,29 @@ ZPMDB: path to local database
 ZPMPACKAGE: package name
 ZPMPKGVER: package version
 ZPMPKGREL: package release
+ZPMPKGFILE: package file
+
+Command Line Options
+--------------------
+
+Used by all programs, so can be passed to zpm
+
+-f package file
 
 Package Selector
 ----------------
 
 -p <package name> -V <package version> -R <package release>
 
-version and release are always the latest available if not specified
-for new packages, version defaults to 1.0, release to 1, but
-may also be taken from the environment
+version and release are always the latest available if not specified for new
+packages, version defaults to 1.0, release to 1, but may also be taken from the
+environment
+
+If there is more than one package name in a database the shortest name is the
+default, and the earliest alphabetically after that.  This makes it so that if
+you have 'db' and 'db-dev' in the same package, db will be the default.  Though
+that's not the way to do it, instead you should tag files within a package, and
+then filter the install.
 
 command line over-rides environment, which over-rides defaults