This commit is contained in:
Joey Hess 2023-07-31 13:50:12 -04:00
parent a7ae014eb6
commit d2a87d4a1b
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38

View file

@ -0,0 +1,34 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2023-07-31T17:12:52Z"
content="""
This seems like a pretty good idea. In particular, I think that the
`not onlyingroup=offline-backup` example is persuasive. The
`field` group example might be able to be dealt with by having
a `collected` group and using `copies=collected:1` in repositories
that only want a copy of data once it's been collected from the field.
Hmm, one problem is that if you have 2 groups that you are using
onlyingroup with, eg
`(not onlyingroup=offline-backup) and (not onlyingroup=offline-archive)`.
A file that is in two repositories, one for each group, will not match.
One way to address that would be something like
`onlyingroups=offline-backup,offline-archive` which would match
on presence in any listed groups. I don't really like that this has
its own ANDing happening inside a term of a preferred content expression
though.
What is onlyingroup supposed to do when a repository is in the
specified group, but also in another group? My first reaction was that
it should never match when content is in such a repository, since the
content is indeed present in another group.
But that doesn't really seem useful.
If it treated a repository that's in the specified group, but also is
in other groups, as matching, then it would be possible to put a repository
in groups offline and backup and match on `not onlyingroup=offline`.
I like this better than the `onlyingroups=offline-backup,offline-archive`
because it's simpler and more composable.
"""]]