Apologies on the really slow response. Also apologies that I wasn't able to fill the knowledge gaps sooner.
It seems as if everyone now understand what happened. If anyone needs anything further from me, please ask. On 23/11/18 01:44, Faustin Lammler wrote: > > Let me check with Otto why this new dependence was added. From what I can see, it was added as a fix[1][2] for a bug[3]. [1] https://salsa.debian.org/mariadb-team/mariadb-10.1/commit/b3e8b645c018d49f7889990e4ad27ca12369cc0d [2] https://salsa.debian.org/mariadb-team/mariadb-10.1/blob/stretch/debian/changelog#L61 [3] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875708 On 22/11/18 21:59, Olaf van der Spek wrote:> On Thu, Nov 22, 2018 at > > https://wiki.debian.org/UnattendedUpgrades Thanks for the suggestion, but as per David's note (in a later message), my testing confirms his experience. If unattended-upgrades is configured for security updates only, then the MariaDB update still fails - albeit not quite so spectacularly. On one hand, I think it could be legitimately argued that not installing the update (rather than removing MariaDB) is preferable in most scenarios. OTOH I'd personally rather know for sure that something is broken, rather than think everything is great when it isn't... I.e. thinking you are automatically getting security updates whilst still running a vulnerable piece of software is far from ideal. On 23/11/18 04:32, Robie Basak wrote: > You should use apt pinning to restrict package upgrades to security > updates only. See what the unattended-upgrades package does for an > example. Removing apt's visibility of stuff that it already has > installed on the system is a hack that will lead to the problem you've > discovered. Thanks for sharing your opinion Robie, although I would argue that explicitly installing updates __only__ from a specific repo (or set of repos - security in this instance) is a desirable and legitimate configuration. (Even if you consider the way we currently do it as a "hack"). FWIW, it's not really removing apt's visibility of what is already installed, it's more removing apt's ability to see what's available from repos other than those explicitly being queried. As noted above, unattended-upgrades still has an undesirable end result - the security update does not occur. I'd be tempted to swap out our simple solution for the the added complexity of unattended-upgrades if it could indeed do what we wanted, but it appears that it can't. Also, as hinted, some of our appliances include third party apt repos which are relatively untrusted. They are already pinned, both for security and convenience. They may also contain newer versions which users will likely not want auto-updated, but at some point may wish to update interactively. We block install of additional software from 3rd party repos via pinning already too (aiming to mitigate potential security risks) but I feel much more comfortable in completely excluding them from auto security updates. Perhaps I'm missing something, but how would pinning to only allow security updates, resolve a scenario such as this? I.e when a new dependency (not hosted in security) is a (new) required dependency of a security update? Wouldn't it at best give the same result as unattended-upgrades? > I'm interested for someone to confirm that pinning will solve this > problem correctly in this particular case. I believe that it will but am > not certain. TBH I'm not even clear where to start with configuring pinning to achieve our ends? I don't understand how pinning could allow you to install and update all packages like "normal"; whilst also allowing __only__ security packages (and any new dependencies?!) to be automatically updated on a schedule?! Although there's a good chance that I'm completely missing something! Could you please elaborate a little on how you think it might work? > I don't know about Debian's policies in adding dependencies to security > updates. Clearly it is to be avoided, but there might be some situations > when it is necessary for security purposes. As Olaf mentioned, I was under the impression that adding new dependencies to security updates is a contravention of Debian policy. FWIW, that's why we felt pretty confident of the config we've been using for the last 10 years. However, my searching has come up empty and I am unable to confirm whether or not that is indeed policy. I will follow up a little further, but if anyone has a reference, please share. > Therefore, I'm not sure that > this should be considered a bug at all from mariadb packaging's point of > view, unless there is some other reason that the dependency addition > should not have gone in. > Well if it's a contravention of policy, I'm pretty sure that counts as a bug, right?! I do agree that there are cases where adding a new dependency to a security update may be legitimate. But I would argue in those cases, adding the new dependency to the security repo as well is the right way to do it (then both our config and unattended-updates would still work as expected). Regardless, it seems to me that we need clarity on policy to decide whether this is indeed a bug or not. My 2c...
signature.asc
Description: OpenPGP digital signature
