Re: etherape - why removed?
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.
Reply to: