> I believe one of the biggest reasons is that because the boot process is very different from the way debian does things, it ends up needing significant change

> I believe one of the biggest reasons is that because the boot process is very different from the way debian does things, it ends up needing significant changes from the starting tasks to do things. Along with that I think the original 32bit RPIs didn't support some version of the compiled binaries in the debian arm repos which meant that they weren't necessarily compatible. No longer correct. Debian on new rPi "just installs" and boots. I think that also worked fine on rPi3 https://wiki.debian.org/RaspberryPi https://wiki.debian.org/RaspberryPi The problem is that many things have not been upstreamed into kernel so some stuff doesn't work or work badly. Like trying to get video just made the video device return random block of memory instead of an image last time I tried > These days on the 64bit version, I'm not sure why it needs that much either. I'd think that having a few new task-* metapackages that setup the boot and raspberry pi specific boot management stuff should be doable and then they could use the main debian packages I would think. There's probably something that's not obvious that makes things just incompatible enough that it isn't simpler to manage that way. I'd imagine the answer is "iteration time". Far quicker to apply a patch fixing some rPi-specific issue if you have your own repo with everything. Pushing it to upstream of Debian might take few days and might come back with "well that code isn't great, fix it". Even more if Debian maintainer says to take it up with original project, which is the right way to do it, just slower one.