Improvements for pool:

pool-register

• pool-register should sync stock immediately - i.e. gather information about all binary & source packages available and calculate all possible versions, etc.

pool-gc

• pool-gc should support garbage collection of one or more specific stocks - rather than forcing full gc of all stocks. If no stocks are specified, it should fall back to the current behavior.
• pool-gc should accept either a stock source dir (e.g./turkey/public/pool) or just the stock name (e.g.pool). An optional#<branch_name> suffix could also be supported - e.g.pool#master.
• pool-gc should also support garbage collection given package name/s too. Support for a wildcard character (*?) might be of value too?

pool-unregister

• pool-unregister should accept either a stock source dir (e.g./turkey/public/pool) or just the stock name (e.g.pool). Again the latter could also support an optional#<branch_name> (e.g.pool#master).
• pool-unregister should support multiple stocks as individual args (IIRC it only supports a single arg currently).

pool-register

• pool-register should support multiple stock paths as individual args (IIRC it only supports a single arg currently).
• (if it doesn't already - need to check)pool-register should support an optional#<branch_name> suffix - e.g./turnkey/public/pool#other-branch.

newpool-sync command

• newpool-sync command to explicitly sync stock/s.
• should accept one or more stock name/s and/or paths - with option#<branch_name> suffix.name/s and/or paths to sync - with optional#<branch_name> suffix.
• should sync all registered stocks if no additional args (i.e. no stock names) given .

pool-refresh

• as perpool-gc &pool-unregister;pool-refresh should accept a stock source path, or stock name - with optional#<branch_name> suffix.
• leverage additional pool functionality to be more efficient.

Currentlypool-refresh requires a stock source path and it's behavior is the same as runningpool-unregister /path/to/stock && pool-gc && pool-register /path/to/stock.

The result is that the cache is cleaned and the current stock is of the source branch that is currently checked out on disk (i.e. current git branch).

E.g./turnkey/public/pool is a registered stock on branchsome-branch - i.e. the stock ispool#some-branch; if a user runscd /turnkey/public/pool && git checkout master and then runspool-refresh /turnkey/public/pool, the result is that thepool#some-branch stock will be removed, the cache is cleared (removing all related packages from the cache) & registers apool#master stock.

Note that currentlypool-refresh will fail if a stock source path is registered multiple times (i.e. multiple branches registered; e.g. bothpool#some-branch &pool#another-branch). The user needs to manually resolve this by performing the specific desired actions.

We could tune behavior in the future, but for now it's probably best for the command result to remain consistent with how it works now. I.e.:

pool-refresh should:

1. continue to fail if multiple stocks (branches) registered for a single path and force the user to explicitly perform the desired action/s.
2. store (probably just in memory) the path to stock source on disk (and the packages that build from that stock?)
3. pool-unregister relevant stock
4. pool-gc - if abovepool-gc behavior is implemented - then only the relevant stock/packages could cleaned.
5. pool-register (andpool-sync) the stock path (as stored initially).

pool-list &pool-get

• ifpool-list orpool-get are only given package/s with a version (i.e.<binary_package_name>=<version>; e.g.deck=1.1), if package and version are already available pool should skip sync altogether. For any versions requested but not found, pool can then sync the relevant stock/s.
• ifpool-list orpool-get are given package name/s without version, pool should only perform a sync of the relevant stocks by default.
• if package/s are given and there is no package name match found in the cached information then pool should fail, with a hint to manually run apool-sync and/or ensure the source is registered as a stock.

[update] these points already covered in another issue:#2070

The newpool-get/pool-list behavior could be implemented by reading all the file names in.pool/stocks/<stock_source>#<branch_name>/index-sources/. Each file found maps to<binary_package_name>. E.g. in the case ofwebmin`:

root@tkldev-pkg .../pools/trixie-amd64# ls .pool/stocks/webmin#2.520/index-sources/webmin webmin-cluster-shell webmin-filemin webmin-iscsi-target [...]

If any package names passed topool-get/pool-list also have version specified (e.g.pool=1.2.0rc4) then the availability of the version can be read from the relevant file - which is a newline separated list of available versions. If the desired version is not found, only then is a sync worth doing. E.g. in the case of the pool package (master branch in stock) the.pool/stocks/pool#master/index-sources/pool file contains:

root@tkldev-pkg .../pools/trixie-amd64# head .pool/stocks/pool#master/index-sources/pool1.2.0rc61.2.0rc5+2+gfbb45591.2.0rc5+1+g8cbdb931.2.0rc51.2.0rc4+1+gdac63f31.2.0rc41.2.0rc2+15+g92813491.2.0rc2+14+gd2dd62d1.2.0rc2+13+g57724911.2.0rc2+12+g70bb2251.2.0rc2+11+g7dc79f0

Given that scenario, if a user runspool-info pool=1.2.0rc5, then after finding and reading that file, no further work is required.