Hi, Am 23.12.21 um 01:24 schrieb Sandro Tosi: > there's also a problem of resources: let's take the example of numpy, > which has 500+ rdeps. am i expected to: > > * rebuild all its reverse dependencies with the new version > * evaluate which packages failed, and if that failures is due to the > new version of numpy or an already existing/independent cause > * provide fixes that are compatible with the current version and the > new one (because we cant break what we currently have and we need to > prepare for the new version)
You can fix the new version and be done with it. (Wouldn't necessarily work for libraries, though, but (build-)deps can be tightened. And if the fix is trivial one doesn't need to do a patch either (although I personally often do anyway) > * wait for all of the packages with issues to have applied the patch > and been uploaded to unstable No, you just need senseful waiting time depending on the issue and then you make the already existing bug RC/you file it as RC to begin with. Noone says "wait until eternity until the last maintainer fixes the package or someone fixes the package if it's unmaintained". > that's unreasonably long, time consuming and work-intensive for several reason I agree that you need to take this with a grain of salt and it depends on the circumstances, yes. And yes, it can be ong, time consuming and work-intensive... > * first and foremost rebuild 500 packages takes hardware resources not > every dd is expected to have at hand (or pay for, like a cloud > account), so until there's a ratt-as-as-service > (https://github.com/Debian/ratt) kinda solution available to every DD, > do not expect that for any sizable package, but maybe only for the > ones with the smallest packages "networks" (which are also the ones > causing the less "damage" if something goes wrong), I've done that for dependencies involving firefox, chromium, libreoffice other big stuff. But yeah, I get the point. In many cases it's not that much, though, especially not if you already know a package which _will definitely_ break by your change. > * upload to experimental and use autopkgtests you say? sure that's one > way, but tracker.d.o currently doesnt show experimental excuses > (#944737, #991237), so you dont immediately see which packages failed, > and many packages still dont have autopkgtest, so that's not really > covering everything anyway Yeah > unstable is unstable for a reason, breakage will happen, nobody wants > to break intentionally (i hope?) others people work/packages, but Evidence shows (in the example I have in mind) this was uploaded with perfectly knowing that it will break. Regards, Rene
