I was working on bug 19055 and realized I wasn't totally sure how we
wanted CLI pattern matching to work, especially in terms of what should
and should not be an error. After talking with Bart and Shawn, I thought
I'd write this up and see if we could come to a consensus so that our
commands only differ where it actually makes sense to have difference.
So here's the state of things today. It seems like we have at least five
similar (but not exactly identical) sets of matching code
1) imageplan.__match_user_fmris.
2) imageplan.match_user_stems
3) catalog.get_matching_fmris
4) merge.expand_fmri
5) api._get_pkg_list
imageplan.freeze_pkgs_match makes use of both __match_user_fmris and
match_user_stems, but could be considered a sixth set of matching code.
We also have some different needs for matching depending on the command
being run. For instance:
* uninstall should only match against installed packages while install
should match known packages
* when a user types 'pkg install foo', we take that to mean "install the
latest version of foo which is installable", but what does "pkgsign foo"
mean (sign all instances of foo, sign the newest instance, sign the
newest unsigned instance ...?)
* if a user provides two instances of a package on a command line, that
could be an error. pkg install entire@1 entire@2 is currently treated
as an error during fmri matching, or it could be perfectly reasonable.
pkgsign entire@1 entire@2.
There are also some things about the current matching behavior that just
don't make a lot of sense to me:
* If a user types "pkg install a* *b" and there's a package named "ab",
why is that an error from the matching code? Similar question for
pkgsign, pkgrecv etc...
Here's how I see the matching the user commands do:
1) Match only against installed packages (uninstall, verify, fix, the
local versions of info, contents, list, unfreeze (more or less)). These
seem uninteresting because the universe of packages to match against can
only contain a single version of a pacakge.
2) Match against the newest (the remote version of info, contents),
these eventually call into api.__get_pkg_list
3) Match against the newest taking existing constraints into account (-a
version of list)
4) Match against all versions (-af version of list)
5) Freeze has it's own approach to matching
Those are all the cli commands (I think). The repo/publishing side of
things...
1) pkgsign and pkgrecv currently use catalog.get_matching_fmris. This
causes a problem for pkgsign because "pkgsign entire@1 entire@2" results
in an error (bug 19055). pkgrecv would also experience an exception, and
while this use case seems less compelling to me (for reasons I can't
really articulate at the moment), I do think a user should be able to
pull more than one version of a package down in a single pkgrecv command.
2) pkgmerge seems to implement its own fmri pattern matching via the
expand_fmri function. It has a different issue w/ "pkgmerge entire@1
entire@2" will succeed, but will only actually merge one of the two
versions of the package. While the manpage does say that pkgmerge only
uses the newest version of every package from each source, it seems like
the above command line should at least be an error. Unless there's a
technical reason I'm not seeing at the moment, I also think it would be
reasonable to change pkgmerge so that it merged all versions of packages
which matched. Roughly speaking pkgmerge *@latest would provide the
current behavior.
3) pkgrepo list uses repo.get_matching_fmris which eventually calls
catalog.get_matching_fmris. Interestingly, "pkgrepo list entire@1
entire@2" works correctly.
Some other interesting behavior related to matching:
"pkg info pkg system-repository" correctly shows me info for 2 packages
but ... "pkg info -r entire@1 entire@2" fails (bug 19060)
So looking at the publisher side of things:
1) catalog.get_matching_fmris is used in pkgrepo, pkgsign, pkgrecv, and
modules/server/repository.py. Of these, all of them set
raise_unmatched=False, so I suggest we remove that optional parameter
and simplify things where possible.
2) pkgmerge should probably be shifted to use the same matching code as
pkgrepo, pkgsign and pkgrecv
3) get_matching_fmris should be changed so that matching the patterns
"a*" and "*b" for a package "ab" doesn't cause an error.
4) Either we need for pkgrecv/pkgsign/pkgmerge foo to get/sign/merge all
instances of foo, or we need for pkgrecv/pkgsign/pkgmerge foo@* to match
all available versions.
As for the cli side of things...
I'd really like to see us have a single matching function there, which
is actually catalog.get_matching_fmris. If we can't commonize w/ the
publishing side of things because the behavior desired is just too
different, I can live with that, but three implementations seems like
two too many on the client side of things.
Perhaps there's a coherent story about our matching behavior (from the
UI perspective) that I'm missing, so please share it if you have one.
Thanks,
Brock
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
