Hi, Ok, so before we get into this deeper, here's another option we've been discussing. Let's drop the non-strict mode entirely, drop OPTIONAL and keep MISC as deprecated-used-to-have-special-meaning alias to DATA.
This is going to make a lot of things simpler, and avoid having the very long discussion on what should be MISC and what not. Especially given that the specific definition of MISC makes little sense as-is. Two reasons have been mentioned for having non-strict mode: 1. Stripping some of non-strictly necessary files to reduce repository size. However: 1a. Stripping of files that we can mark MISC is not going to do much. Most of the time, people would strip whole categories or other data we can't really mark MISC, so they will need a different solution anyway. 1b. That's just an argument for allowing them to be missing. There's no clear reason why they would have different content, and it doesn't have much sense to allow it implicitly. 1c. Those files can still be means of doing some kind of attacks -- starting with misinformation resulting in the user reducing security of his systems, ending with attacks e.g. exploiting XML parser vulnerabilities. 2. Allowing different content for cache-class files that can be updated on user's end (e.g. md5-cache, use.local.desc...). However: 2a. We can't really do this for md5-cache since it clearly can be abused. 2b. Again, it makes little sense since we took special care that all those tools have stable output. All that said, if we really have a problem that needs solving here, I'm not convinced MISC is the right solution for it. If people need to explicitly exclude stuff, then I suppose the configuration-injected ignore list is much better solution for this. -- Best regards, Michał Górny
