On Mon, Oct 20, 2003 at 07:46:27PM +0200, Goswin von Brederlow wrote: > Andrew Suffield <[EMAIL PROTECTED]> writes: > > > On Mon, Oct 20, 2003 at 12:13:22PM +0200, Goswin von Brederlow wrote: > > > > b) The package is uploaded from real-world environments. Sometimes it > > > > breaks; when this happens the bug is noticed and corrected, so that > > > > the package always builds the same way. > > > > > > Why would it ever be noticed? That only happens if someone manually > > > rebuilds the package and notices a difference. Something like being > > > linked against different versions of libc or even different versions > > > of libpng might go unnoticed for a long time. > > > > If you are arguing that such issues will not be noticed, then you have > > just defeated your own argument. > > > > Your argument has been founded upon the notion that packages built on > > real-world systems might be broken. You are now saying that nobody > > will notice - in which case it doesn't matter at all, and the status > > quo should remain. > > There are lots of cases where the source is broken or the used > libraries are not what they should be that don't make the programm > segfault. A user might never notice the difference. > > At the moment, unless someone manually rebuilds, a binary-all package > can be completly unbuildable unless you have the exact same > environment as the maintainer and do the same dirty hacks he did to > build. > > The case where an uploaded binary just does not run is pretty uncommon > and will get noticed by the first user updating. Thats what sid is > for. I'm not realy concerned with bugs in the binary (in this > discusson), source only uploads wont do a think to change them.
Okay, you're committing the fallacy of affirmation of the consequant. Your implication is: "If we only make source uploads, then this problem won't happen" And your assertion is: "We don't want this problem to happen" From this you derive the conclusion: "We should only make source uploads" This is logically invalid. When the consequant is true, the antecedent is irrelevant. Translating this into practical terms, you're wrong because we could fix this problem in other ways. For example, we could build the arch-indep packages someplace and not bother to upload them. Hey, that's what actually happens. It just isn't automated yet. > > > > I say that (b) is vastly superior to (a). The tradeoff is temporary > > > > bugs in sid versus unnoticed bugs in a release. We'll never trap all > > > > the bugs, but going out of your way to _not look_ cannot be a good > > > > idea. > > > > > > You say that in case B bugs will be noticed, which implies people are > > > recompiling the packages in their own environments. But then bugs > > > would just as well be noticed in case A. > > > > > > So far the best suggestion for this problem I have heart was to allow > > > (require) binary uploads but to hold them back and autobuild > > > everything for all archs. Only binaries allowed into archive are > > > autobuilders and binary-only uploads (to allow fixing autobuilder lags > > > or problems). > > > > It is evident from these two paragraphs that you did not read my mail > > and understand it. I have already given reasons for why they are > > wrong, albeit not attached to the same examples. > > You reason for case B (that people will test build and find bugs) > just as well applies to case A. That makes your point void. Empirically false. In fact, you've missed the point entirely, since that *was* the point. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
signature.asc
Description: Digital signature
