Web lists-archives.com

Re: etherape - why removed?




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