Re: stable vs. testing: same versions, different status
On Wed, 10 Jun 2009 20:22:39 +0200, Francesco Poli wrote:
> > the best course of action here is to use stable-security with a higher
> > pin-priority than testing;
>
> I think it would work correctly with the *same* pin-priority as used
> for testing and testing-security.
agreed. i didn't fully think through the implications because i've
never thought about this sort of configuration before.
> > of course this is a less-than-desirable situation because most users
> > won't go through the trouble.
>
> I think this solution could be viable, but should be considered
> sub-optimal, as it would require suggesting all (Debian testing)
> end-users to modify their sources.list.
or if the testing installer does it, then it is automatic.
> Moreover, the security-tracker would not be aware of this possibility
> and would thus go on considering those vulnerabilities as unfixed for
> testing.
the web tracker shouldn't be the definitive source for the security of
your particular configuration. use debsecan. it takes into account the
specific versions of the packages you have installed.
> On the other hand, my proposed automatic stable-security ->
> testing-security migration mechanism would fix a number of
> vulnerabilities (especially in the first post-release times) for all
> Debian testing end-users, in a "gratuitous" manner (from a Debian
> Testing Security team point of view, since it would re-use the Debian
> Stable Security team effort).
if you are interested in this feature, then by all means, volunteer
and implement it. if you are interested in assisting the security
team, then they will be happy to have you help; regardless of whether
or not you don't exactly meet the qualifications. everyone can learn.
however, i think that the feature is here now (via stable-security), and
i personally don't see the need to implement this harder solution
(especially since testing is not currently considered security
supported anyway).
based on the track record for lenny, you can probably expect full
testing security support sometime within 6 months to a year before
squeeze's release (i.e. around 18 months after lenny's release or over a
year from now).
in the meantime, if you are interested in security support, you should
stick with stable. if you are interested in low numbers of security
issues, but not necessarily guaranteed security support, then unstable
is also a reasonable option; and to be honest, it doesn't break much any
more since most potentially dangerous updates are staged in experimental
beforehand.
in my case, i run stable on raw metal, and i run unstable inside of a
virtual machine (kvm) to get access to the latest versions of
applications if i so desire; while concurrently minimizing lossage due
to breakage (i could also set up snapshots just in case, but i haven't
had the need yet). i'm fairly pleased with this set up.
mike
Reply to: