1 zpm: always a shell script, that way it can source config files and export environment
2 variables for sub-programs
4 Good to have a program to check if a package exists. That is, would
5 zpm install do anything, at least notionally.
9 1: working on the local database and manipulating packages
10 This is where 'install' 'update' 'remove' etc are done.
11 Additionally, this is where notes, bug reports, repo
12 control, and so forth are done. Since this is the most
13 common mode, these commands shouldn't need a prefix or
14 something saying we're dealing with the local package DB.
16 2: working on a package file.
17 This is where building a new package, adding files, and otherwise
18 dealing with package metadata happens
20 3: working on a repository of package files
22 Since 2 and 3 are the less common operations, they can have
23 more verbose syntax, also, 2 "expects" a package file, so
24 require an option to force using the local DB, and 3 expects
25 needs repos, perhaps force not using local DB
26 Difference between working on a repository, and manipulating
27 repository info for the local or other DB
28 And 1 expects the local db, so option to specify package file.
30 -f for package file? or -p? and for cat 2, take as argument if
31 not specified? perhaps an option to construct? probably
32 not, have a program to construct if needed.
34 Need a way to specify a non-default local database location,
35 /var/lib/zpm/local.zpm by default
40 Conceivably for 2: 'zpm -f <pkgfile>', since if it's not the
41 local package database, you'll have to specify the package file
43 install: will search the repos for the most recent package.
44 of install a from a package file given with -f.
46 so zpm install -f 'pkgfile' will install all packages in that file
47 zpm install -f pkgfile package will install just the named package
48 zpm install -f pkfile package package2 will installed both packages
49 zpm install -f pkgfile -V 1.2 will install version 1.2 of all packages
50 that have a version 1.2
51 zpm install -f pkgfile foo-1.2 will install version 1.2 of package foo
53 zpm install foo will install the most up to date foo from the
56 zpm install foo-1.2 install version 1.2. how to distinguish
57 between versions and package names with hyphens? Use @?
59 Package filters: Version, release, name, min/max version, min/max release
62 File filters: Get everything, except exclude by tag, which will
63 exclude every file with the tag. Can reverse sense, and get
64 nothing, except what's in tag. +tag will add a tag to the set,
65 -tag will remove it. 'tag' sets the tag list
71 Always set by the zpm wrapper.
73 ZPMDB: path to local database
74 ZPMPACKAGE: package name
75 ZPMPKGVER: package version
76 ZPMPKGREL: package release
77 ZPMPKGFILE: package file
82 Used by all programs, so can be passed to zpm
89 -p <package name> -V <package version> -R <package release>
91 version and release are always the latest available if not specified for new
92 packages, version defaults to 1.0, release to 1, but may also be taken from the
95 If there is more than one package name in a database the shortest name is the
96 default, and the earliest alphabetically after that. This makes it so that if
97 you have 'db' and 'db-dev' in the same package, db will be the default. Though
98 that's not the way to do it, instead you should tag files within a package, and
99 then filter the install.
101 command line over-rides environment, which over-rides defaults
106 The primary executable is zpm, which is a shell script. This script
107 sources (if they exist) in order, /etc/zpm.conf ~/.zpmrc
109 The script then parses its command line options up until the first non-option,
110 export environment variables, and looks for a command of the form zpm-$1 which
111 it then executes. If the ZPMPATH is not set, it looks in PATH and if that is
112 not set, in /sbin:/usr/libexec/zpm
115 -f <database file> -- they're the same option, just different way of thinking about it
120 Very low level commands to manipulate a database. These can be used directly,
121 but are primarily intended to be wrapped up in shell scripts. Each of these
122 should also have an equivalent in the C library API. The zpm- prefix is omitted below.
124 newpackage: add package metadata to a zpm database, creating the target file if
127 -N require the target file to not exist (new)
128 -A require the target file to exist (add)
129 -P packager string, should be an email, use ZPMPACKAGER environment
131 addtopackage: add a file to a package
133 -C <n> number of leading components to strip
134 -P <path prefix> prefix to strip
135 -H hard coded path, regardless of the source
136 -T track only, don't import the contents
137 -c flag as configuration file
138 -t <tag list> comma or space separated tags on file
140 zpm -f foobar-1.0-1.zpm addtopackage /usr/bin/foo /usr/bin/bar
141 zpm addtopackage foobar-1.1-3.zpm /usr/bin/foo /usr/bin/bar
142 zpm add -f foobar-1.1-3.zpm -p bar /usr/bin/bar
144 need to think about the syntax here, but best to just write something,
147 extract: pull file content to disk
148 $1 is hash or hash prefix if unique, $2 is target path
155 -D don't create leading directories
157 list: list package contents
159 -F <format> %p path %m mode %o owner %g group %h hash
160 -N don't append a newline to format
161 -0 append a null byte to the format
163 default format is '%h %m %o %g %p'
166 maybe reverse list and show
168 drop: delete a package
170 delete: remove a file from a package
172 adjust: adjust file metadata
174 Higher Level Commands
175 ---------------------
177 install: install a package to the local system
178 search repositories known in the local db for a matching package
179 remove: remove a package
180 update: update a package
182 -D dry-run, just show what might be done
184 export: create a standalone package file from a repo/localdb
186 json: dump the metadata of a repo as json
191 A repository is just a collection of packages. All in one DB, or perhaps
192 mark an external file location for package contents.
194 Repository Definition is just a url.
195 Has a priority. Can require trusted signer. Can require confirmation.
196 Install/Search will ask on tied priorities. Warn on lower priorities.
198 Fetch a repo by getting the json file, or by getting a stripped down DB file.
200 repo import: adds repository information from the json file
201 repo drop <url or name>
202 repo add <url> [name]
203 repo refresh: update repository info
205 repo command needs to know how to get metadata from local files
206 for http[s] urls, path given should return either json or sqlite db, responsibility
207 of repo to make this work
212 build: builds a package file
213 -S read paths from stdin
215 Reads PKGBUILD in the current directory
216 -b build script path instead of PKGBUILD
221 absorb: pull in the content of a file. note the mtime if it's a config file, possibly
222 keeping multiple versions
224 truncate: drop the content of a file
227 investigate the status of a repo, reporting things like failed installs or removes,
228 file conflicts, anything else
230 integritycheck: compare the stored hashes with the hashes on disk
233 add a note file, - from stdin, list if none
239 acknowledge a note file
242 compare two versions of a package, show what would be done
246 get information on a package
249 add a package to config tracked packages
251 add: add to a repository/database
253 clean: clean a repository/database