Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's mainly three kinds of patches:

* make the software behave like Debian needs it (configuration is stored somewhere in /etc/, no additional downloads at runtime, use the system libraries instead of vendored ones) * security backports. Debian freezes the functionality at release and only provides security updates. Many software nowadays just includes security fixes in new releases bundled with new functionality.

In combination these two kinds of patches lead to growing differences between a Debian released version 1.2 and the "real" 1.2, making it harder to handle bug reports (e.g. you get a bug report for version 1.2-Debian, but only support the "real" version 1.4 with a whole set of updated libraries).

The third kind of patch has mostly gone out of style; it's when Debian thinks they can improve the software. That lead to things like removing randomness from SSH keys: https://github.com/g0tmi1k/debian-ssh



Another kind of patch is when a common dependency library is being updated, and laggard upstreams need patching to make their current releases work against the newer library; it's either that or a Debian release with those packages missing.

This type is actually really common. Debian packages something like 30k upstreams, and so some are always behind.


Do they just patch the package in Debian or do they submit them upstream?


Usually both, submit upstream and add the patch to Debian while waiting for upstream to accept the patch.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: