On Mon, 24 Jan 2005, Jeroen van Wolffelaar wrote: > On Mon, Jan 24, 2005 at 01:46:30AM +0100, Santiago Vila wrote: > > That's the correct explanation, yes. It has never been a bug to build > > a package using stable if the dependencies are compatible with the > > ones in testing. In this case, Pre-Depends: libc6 (>= 2.2.4-4) is ok > > because sarge has 2.3.2.ds1-20 and libc6 is not in oldlibs. > > Well, it is recommended to build in sid, also, I do think building in > woody is bad for several reasons: > - you do not ship what's in sarge, you cannot reproduce the build > because it was build with software not in sarge. This is often the > case in minor ways, but intentionally doing so seems awkward at best.
I agree it's a little bit awkward, but the build is done on 10 different architectures. If there were a FTBFS problem, chances are that I would be notified about it. > - only one architecture will have these older woody depends, all other > architectures not. I don't know what reason you have to build on > woody, but that's defeated by this buildd reason. If somebody using the i386 architecture (which is the most common one) reports a bug and it's fixed in the package in sarge, I can point the user to the URL of the fixed package, and he/she can install it without having to upgrade libc6. I think this is definitely a good thing, but I now agree that it might not compensate for the potential bad things. > - Suppose one day after sarge is released a security update needs to be > made, and this package is suddenly build on sarge. There might be > weird bugs hiding there, since nobody tested it this way, only builded > on woody. I think it's very important to make sure security uploads > are not going to change the package in bad ways, and suddenly building > with a much different libc et al, and a different gcc with different > properties apparantly (this bug is directly caused by it) might be > resulting in such bad changes, we simply don't know, since it hasn't > been tested. Yes, I understand that, and I mostly agree. Now please write a lintian warning for PT_GNU_STACK. Mass bug filing me even before a lintian warning exists is not polite. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
