On 2018-04-09 at 10:31, Hans wrote: > Hi Roberto and the Wanderer for making some things clear. My fault, > that I interpreted the website of tracker not correctly. > > However, it is not understandable for me, why a package has to be > removed (due to a bug) instead of keeping the last running version, > and then, when a newer and running version exists, to substitute the > latest running version with the higher version. I'm not entirely clear which version(s) you're referring to by each of these, WRT "the version in stable", "the version (which was) in testing", and "the version in unstable". The version in stable does not get removed; it's still there, in stable. The version in testing can't be retained, because it had a bug which would have made releasing it as part of the next stable inappropriate, and the entire purpose of testing is to develop into the form which will become the next stable. When a package version in testing develops a bug which is unsuitable for stable, restoring the version from stable into testing would not be a good idea, because it would mean that someone who had already installed the (higher) version from testing would see the version number available in testing go *down*; such a person would never see the stable version listed as a possible upgrade. The confusion which results from version numbers going backwards and forwards is almost never worth it. All else being equal, a package in unstable will eventually make it into testing - but the purpose of unstable is to make it possible to detect bugs in packages which haven't made it into testing yet, so that those bugs never make it into testing. Letting a package skip the unstable period and go right into testing would defeat the purpose, and would mean that it's *more* likely that the package in testing would turn out to have a bug that would cause it to need to be removed. > Or equals, subtitute the latest running version with a fixed > version. Where is this fixed version supposed to come from? When a fixed version is created, it's always possible that the fix will introduce another bug, which wasn't present before. In order to make it possible to detect such bugs and keep them from getting into testing, new versions have to go into unstable first; they only get migrated to testing after they've had a while to "cook" in unstable. To permit a package version to go directly into testing, without passing through unstable first, would defeat the entire purpose of having there be an "unstable" in the first place. > To remove a defektive version completely in testing is IMHO not the > best way. When the defective version introduces problems for other packages, keeping it around can be worse than removing it. That is in fact one of the criteria for deciding to remove a package from testing. If I read you correctly, you're suggesting that when this happens, the "last known good" version should be reintroduced, rather than remove the package entirely. Unfortunately, there are at least two reasons why this would not work well in practice. One is the problem with package version numbers effectively going backwards, as mentioned above. The other is about package dependency relationships. For example, if the "last known good" version (from stable) depends on an old version of a particular library, and the version of that library in testing is too new to work with the package from stable, bringing back the stable version would require bringing back that old library - and that would require removing all the package which depend on the new version. Basically, the idea isn't impossible, but it would introduce far more problems than it would solve. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature