Code review comment for lp:~cwarner/unattended-upgrades/whitelisting

Revision history for this message
Christopher Warner (cwarner) wrote :

Yeah this looks good, about the whitelisted strings. I battled with the dependency issue as I can't tell if that would necessarily be an issue going forward for our needs specifically but for the greater good i'm assuming others wouldn't want to deal with the inconsistency. Operating on the notion that a dependency would be apart of an overall update maybe we should just allow it?

So for example someone wants to use whitelisting and they automatically assume deps are included: whitelist bash, then bash and any deps would be whitelisted. So in the case of Ubuntu, Canonical would test/smoke/vet an update of x.pkg with x.pkgs && deps. That should cover most cases, specifically if it's a security update. In the cases where one wants to hold back a dep of a whitelisted package, they could simply forcefully downgrade or link to the dep at runtime or install from source and point to the dep they care about or etc.

The opposite side of the coin is I assume all deps are upgraded and they aren't. If a lib is a dep, it's possible i'm loading upgraded executables looking for undef'd refs unattended or all the other nasty things. Of course I don't have the data to prove which use case would be a more common rationalization. It just seems like if you ok the whitelist pkg any deps surrounding it should be considered OK for unattended-upgrading.

DISCLAIMER: If this comes back to bite me in the ass at some point I'll whine about it, wave my hands and then blame you.

« Back to merge proposal