authorative-cache should only be enabled if the repository has no masters (even if the repo has authorative-cache = true in layouts.conf), since the cache depends on the master. authoritative-cache should only be used if the user enables it, as he must not modify the repository. FEATURES="trust-authoritative-cache" as suggested by ferringb lets the user enable authorative-cache. It should be disabled by default to get the user to confirm that he understood the implications.
We could make this a repos.conf setting, instead of using FEATURES. The user could set something like this to enable it globally: [DEFAULT] authoritative-cache = true And then the could do separate settings for individual repos if they want.
(In reply to comment #1) > [DEFAULT] > authoritative-cache = true We could also have a separate "trust-authoritative-cache = true" setting that would only enable it if "authoritative-cache = true" is also set in the repo's layout.conf.
(In reply to comment #2) > (In reply to comment #1) > > [DEFAULT] > > authoritative-cache = true > > We could also have a separate "trust-authoritative-cache = true" setting that > would only enable it if "authoritative-cache = true" is also set in the repo's > layout.conf. validation should only be disabled when the repository specifically says it's viable to do so- such a repository would basically have to be git vcs distributed (not rsync) to allow for folding the cache into each rev, so that when you checkout a specific rev you always have the cache for that distinct rev. Keyword here is 'authorative'; if a generic "disable validation" option is desired in the user config, it really shouldn't confuse the layout.conf provided hint.
Okay, repos.conf now supports "trust-authoritative-cache = true|false" settings for each repo and via the global [DEFAULTS] sections: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=b33e1b6d26f9c4df6a1b6773e5471e2caa1012b3 (In reply to comment #0) > authorative-cache should only be enabled if the repository has no masters (even > if the repo has authorative-cache = true in layouts.conf), since the cache > depends on the master. The masters could only cause problems if they provide eclasses that modify metadata, so it would be heavy handed to disable authorative-cache simply due to a masters setting alone. Note that masters can be used to satisfy deps for repoman, and doesn't necessarily imply sharing of eclasses, nor does it imply that the eclasses modify metadata. If we need finer grained control, we can add additional layout.conf/repos.conf attributes.
This is fixed in 2.1.10.21 and 2.2.0_alpha61. > (In reply to comment #0) > > authorative-cache should only be enabled if the repository has no masters (even > > if the repo has authorative-cache = true in layouts.conf), since the cache > > depends on the master. > > The masters could only cause problems if they provide eclasses that modify > metadata, so it would be heavy handed to disable authorative-cache simply due > to a masters setting alone. Note that masters can be used to satisfy deps for > repoman, and doesn't necessarily imply sharing of eclasses, nor does it imply > that the eclasses modify metadata. If we need finer grained control, we can add > additional layout.conf/repos.conf attributes. If still interested in constraining the use of authoritative-cache with masters, there's a buggy patch here: http://dev.gentoo.org/~ferringb/0001-allow-authoritative-cache-only-via-force-when-master.patch
