In article <[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
>> If the buggy version is still in stable or testing, you should have a
>> dependancy or conficts to avoid it.
>Now I know why we call it unstable :-) I also read from your email that
>this allows dropping a versioned dependency (>= n) once version >= n has
>entered stable. That makes sense.
I was also assuming the bug had already been fixed in unstable.
Unstable does have problems at times, even if they tend to be less
than the ones I experinced with redhat.
>Let me think this through: Once a buggy package has entered testing but
>was replaced by a version which fixed the bug, no versioned dependency
>against it is required in my package, because we care only for a working
>stable release, a working *current* testing and a working upgrade path.
>Right?
Not required, but certainly not prohibited. It's hard enough to
support oldstable (security only), stable, testing, and unstable
without trying to support every possible version that has ever
existed. Since the bug was in another package that is no longer
available, you don't have to go out of your way to support or avoid
it.
--
Blars Blarson [EMAIL PROTECTED]
http://www.blars.org/blars.html
With Microsoft, failure is not an option. It is a standard feature.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
