On 10/02/2011 04:22 PM, Brian Harring wrote:
> On Sun, Oct 02, 2011 at 02:10:09PM -0700, Zac Medico wrote:
>> On 10/02/2011 01:54 PM, Robin H. Johnson wrote:
>>> On Sun, Oct 02, 2011 at 01:39:41PM -0700, Zac Medico wrote:
>>>> On 10/02/2011 05:46 AM, Robin H. Johnson wrote:
>>>>> On Sat, Oct 01, 2011 at 09:40:13PM -0700, Zac Medico wrote:
>>>>>> If we control these hashes via metadata/layout.conf, then we can toggle
>>>>>> it atomically for all commiters. Otherwise, we'll have an annoying
>>>>>> period of time where different committers are committing different sets
>>>>>> of hashes, depending on their portage version.
>>>>> How do you suggest doing it via layout.conf? I've kept SHA256 in both
>>>>> sets for now, but if you could enforce new signatures including both
>>>>> WHIRLPOOL and SHA256, that would be great.
>>>> How about if we put something like this in
>>>> gentoo-x86/metadata/layout.conf now:
>>> Did you mean profiles/layout.conf? I just want to make sure no scripts
>>> that pull from CVS and expect that dir to not exist don't break.
>> No, it's metadata/layout.conf. I didn't choose the location. We actually
>> inherited it from paludis about 1.5 years ago:
>> http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=f16aee82cefa95e9903fa46f448 d30f6d4350f64
>> We're also using it to control thin-manifest support, among other things
>>>> manifest2-sha1 = true
>>>> manifest2-whirlpool = false
>>> Bikeshedding slightly, but can we figure something like a list or dict
>>> instead? (Also gives us a chance to make the required hashes a list).
>>> manifest2-hashes = ['SHA1', 'SHA256', 'RMD160']
>> Well, booleans are simpler. Also, note that I designed them to be
>> removed from layout.conf eventually, which means that we will accumulate
>> less bloat in layout.conf over time.
I've implemented it with booleans in this commit:
> Should use a space delimited list instead named hashes instead; those
> being the hashes that should be generated, and that can be /used/.
> Not in the list, not an acceptable hash (even if a manifest2 carries
> that data).
Why? Boolean flags are simpler and they work.
> If it's not set, then the pm defaults in a list; that default list
> should be tracked somewhere (rather than just whatever the PM author
> decides) also, although that's a seperate discussion.
Sure, it could be added to PMS or something.
> Breaking it out into individual booleans isn't particularly great; we
> use lists for masters, a tristate for use-manifest, etc. Having each
> CHF controlled by a seperate boolean adds more toggles than is worth
You can group them into a dictionary, like I did.
> it imo, and having the manifest2- prefix makes the parsing slightly
> more complex while also making the key name a bit daft if we ever
> switch to a manifest3.
I made it manifest- instead.