| === JanC_ is now known as JanC | ||
| jjohansen | JanC: it shouldn't. To build in the security pocket the dependencies have to be met | 04:58 |
|---|---|---|
| jjohansen | so if it is really needed, by a security update the dependency from the updates pocket will get pulled in | 04:59 |
| jjohansen | you can have -security without -updates | 04:59 |
| jjohansen | but yes you may get updated versions because over time through -security | 04:59 |
| JanC | binary packages in -updates that are dependencies of binary packages in -security get copied from -updates to -security, even if they aren't security updates themselves? | 05:02 |
| jjohansen | only if necessary for a security update | 05:03 |
| JanC | well, the security update might depend on an unrelated non-security API extension in -updates, or something like that :) | 05:04 |
| jjohansen | without doing that you couldn't have security without updates | 05:04 |
| jjohansen | yes, but we do try to avoid that | 05:04 |
| jjohansen | dependencies are a pita | 05:06 |
| jjohansen | that is why every body wants to containerize their apps, vendoring all their dependencies in | 05:07 |
| jjohansen | so instead they get to deal with the problem of their dependencies never getting proper security updates instead | 05:07 |
| JanC | "everybody" | 05:08 |
| jjohansen | :) | 05:09 |
| jjohansen | what can I say, I can't spell worth a ****. Product of the education system ;-) | 05:09 |
| JanC | I meant, that needs some quotes | 05:10 |
| jjohansen | ah, well yes that too | 05:11 |
| codingkoopa | "only if necessary" ah okay, at first I was thinking that there is a direct heritage for each package going back and forth between -security and -updates without any offshoots | 16:11 |
| codingkoopa | This all sounds... complicated, to maintain ;) | 16:11 |
| codingkoopa | So -updates *always * integrates security fixes, and -security integrates other bug fixes as necessary? And then the -updates version is (generally) the one used when creating a new point release? | 16:14 |
| codingkoopa | I'm not trying to oversimplify the process, I understand that a lot of this is situational ^^ | 16:15 |
| codingkoopa | I think the thing that still confuses me is that, if there is a new -security update that is deployed, then a user would see regressions in the forms from any non-security-bug fixes that were not integrated. | 16:16 |
| codingkoopa | e.g. package foo from xenial-updates has bugfix X, and then xenial-security has to patch vulnerability Y, and does so without integrating bugfix X - then the user gets the security fix, but is missing out on the other bugfix | 16:18 |
| jjohansen | codingkoopa: yes, its a trade-off between work to be done and potential for regressions | 18:29 |
| jjohansen | if we did a security pocket for each release, so that, that release only received the security fixes, and then a security pocket for updates. That increase the amount of work that needs to be done. Partly because you have to apply the security fix in two places, partly because the further release and updates drift the larger the potential for patches to need additional backporting work. | 18:31 |
| jjohansen | But it gets worse as we would then need a security pocket for each point release as well | 18:32 |
| jjohansen | as for seeing regressions for non-security-bug fixes that were not integrated. Its possible and has happened | 18:34 |
| jjohansen | security fixes go through both a build and run testing, but we can't catch everything | 18:34 |
| jjohansen | in those cases, we might revert until the regression is fixed or we might be able to pull in a fix right away and re-release as a regression fix, those would show up as -2 or -3 ... as part of the USN number | 18:36 |
| jjohansen | though we are also using -2 ... for ESM now too :( | 18:38 |
| jjohansen | an example of an update fixing a regression https://ubuntu.com/security/notices/USN-5487-2 | 18:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!