Am Montag, 9. April 2018, 17:48:21 CEST schrieb The Wanderer: Hi The Wanderer,
thank you for this detailed and very informative response. I think, this makes everything clear for me, and my little question is solved. However, I will read your message severalt times, so I do understand it fully, and I will think about your arguments. At the first glance they are logical and accountable on the other hand, and I suppose, you will understand this, it is irritating, that a package suddenly disappears. I am regularly building my own kali-linux versions, and when an important package like etherape suddenly disappears, this is sad. Of course, the solution is, to put the latest running package into the package-chroot of the life-build environment. But it is good to have taĺked about this, I think others read interested this thing, too. So, thank you and and all others for the help and clearance and have a very nice week! Best regards Hans > 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.