* Frank Küster: >> We aren't prepared to deal with that in some important cases. For >> instance, if large numbers of identically-versioned binary packages >> are published, there will quite a few issues in the short term . > > Hm, what problems are you talking about?
Right now, if there's a bug report in the BTS that, for example, cook 2.26-1 has been miscompiled on amd64 and has got an important bug as a result, we can be pretty sure that the submitter talks about the version in our archive. If there was a separate buildd network that did not upload to the official archive and was somewhat popular among our users[1], it's no longer obvious which version is broken. (And for interoperability with various bug tracking efforts, you'd really want to keep the official version numbers.) [1] It could be more up-to-date, use more conservative GCC defaults (-fwrapv -fno-strict-aliasing -fstack-protector), or provide an audit trail that gives people a warm fuzzy feeling. >> (and fear of such confusion already led to drastic measures on >> behalf of the project) > > What measures? Can you provide any links? <http://lists.debian.org/debian-devel/2007/01/msg00760.html>
