| opendevreview | Roja Eswaran proposed openstack/diskimage-builder master: Replace debootstrap with mmdebstrap https://review.opendev.org/c/openstack/diskimage-builder/+/987717 | 15:35 |
|---|---|---|
| JayF | https://review.opendev.org/c/openstack/diskimage-builder/+/987717/9#message-0ea1b18dfa793922436fdadcf0d9088036b27c5b if other cores think this stance is too risk-averse, let me know and I can throttle down :) | 20:45 |
| JayF | I'm willing to admit that the recent shenanigans around supply chain attacks has me more nervous than usual about software that's "X, but better!" | 20:46 |
| clarkb | I'll let fungi weigh in on that one because fungi seemed to think it was a good idea. Its possible within the debian community everyone already expects this tool at this point? | 20:51 |
| clarkb | I think supporting the tool is fine. And I'm happy to have it behind a config option if we think that is good for user expectations | 20:51 |
| JayF | Someone more embedded in the debian community being like "this is 100% the new way" would completely remove my concern | 20:55 |
| JayF | I just don't like one-way migrations, especially when they are silent | 20:55 |
| JayF | someone runs dib today; does an apt install; runs dib again and gets different behavior | 20:55 |
| JayF | feels kinda nasty? | 20:55 |
| clarkb | well only if they have installed the tool | 20:56 |
| JayF | but that's not even what I'm complaining about; I just want the user in that position to get to revert | 20:56 |
| clarkb | which presumably they would do if tehy want to use the tool | 20:56 |
| clarkb | they can, uninstll the tool | 20:56 |
| JayF | well sure, maybe I tried it out to see if it was good or not, and went "wow, I'm glad I'm using Nice Stable DiskImage-Builder(tm)" | 20:56 |
| JayF | and then was shocked to see my dib-based build break too :D | 20:56 |
| JayF | lol | 20:56 |
| JayF | or even build servers shared between dev/staging/prod | 20:57 |
| JayF | you gotta flag day it | 20:57 |
| clarkb | ya maybe. I mean in opendev we've been using dib in isolated installation envs for years and years. First in container images and now in throw away zuul jobs. | 20:57 |
| clarkb | so we've always had strict control of what tools are used and this wouldn't affect us. If this is still not an expectation on the debian side then I agree having an opt in control for it is a good idea | 20:57 |
| JayF | the pattern I've seen, in practice, is: 1) operator develops DIB build on "local" linux machine, 2) operator translates that working build into ansible/jenkins/whateverCI | 20:58 |
| JayF | so running it local does happen :) | 20:58 |
| fungi | yeah, i think it could be done in a more backward-compatible way, but ~nobody in debianland uses old debootstrap since many years, it was supplanted by cdebootstrap and later mmdebstrap and also some container-based efforts (kinda fragmented) | 20:59 |
| JayF | if you put that comment in under mine, I'll pull my -1 | 21:00 |
| fungi | well, i did comment about it previously on that change, but it's fairly down my priority list with everything else going on | 21:01 |
| fungi | mainly it would be great to get a massive speedup on opendev's debian and ubuntu image build jobs, but things are already working as-is too | 21:01 |
| fungi | and we wouldn't be able to take advantage of it right away because we pass additional debootstrap opts to disable mirror signature verification, which would need to be plumbed differently for the equivalent mmdebstrap option | 21:03 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!