>= 1.1 && < 1.1.234 || >= 1.1.235 && <= 1.2.8754 || >= 1.2.8755 ... && < 1.4
I’m not concerned about this in that packages already do this to avoid particular known-buggy releases, and having an advisory database does not change this situation in any particular manner. So it seems orthogonal.
I would think that the synchronization to Hackage could be a git pull
, and that Hackage could otherwise be set to read our standard file format. Then, it can put links to advisories on each affected package/version page, along with the README, the maintainer, etc.
This is all rather technical architecture stuff here, but are you suggesting hackage runs a “git pull” of the advisory db? I would tend to prefer hackage itself continue to not run any pull based processes, and we instead have another tool (with authorization) that runs the pull and then uploads to hackage in a specified format. Internally, I think hackage should extend its datastructures to maintain a map of “packagename → [advisory]” and then query this on render, to keep the advisory feature as not-intertwingled as possible with existing functionality. I’m partially just sketching this for my own future reference.