On Tue, Aug 19, 2003 at 06:02:24PM +0200, Goswin von Brederlow wrote: > Andrew Suffield <asuffield@debian.org> writes: > > > On Sun, Aug 17, 2003 at 07:45:31PM -0500, Joe Wreschnig wrote: > > > On Sun, 2003-08-17 at 18:02, Andrew Suffield wrote: > > > > On Sun, Aug 17, 2003 at 01:02:13PM -0500, Joe Wreschnig wrote: > > > > > I long for the day when binaryless uploads are mandatory (and this is > > > > > coming from someone who's been bitten by FTBFS more than once ). > > > > > > > > Somebody comes up with this about once every month or two. It remains > > > > bogus. Why do you think that it would be more likely to build if the > > > > maintainer builds it zero times instead of one? It seems fairly > > > > evident to me that this would make FTBFS issues *more* common, not > > > > less. > > > > > > Because if it doesn't build, it doesn't enter the archive, because there > > > are no packages to enter the archive. > > > > Firstly, that's just wrong. The source package would enter the archive > > and fail to build - so you'd have a package which was out of date on > > _every_ architecture. > > Thats a matter of changing the archive to keep sources out of the > archive until an autobuilder has build it. Not sure how that would > work with the current system but it would be possible and preferable. It's called "testing". > > Secondly, in the current system, if it "doesn't build", then the > > maintainer would not be able to upload the package at all, because > > their build of it would fail. Source-only uploads would _remove_ this > > check, thereby making FTBFS issues more common. They certainly > > wouldn't prevent any problems that currently happen. > > Then where do those debs come from that just plain don't compile for > some obvious reasons? Clearly it does compile, because the maintainer has compiled it. > Maintainers are lazy. They run a full build which fails at the end, > they fix the typo and then just rebuild the debs and forget the > sources. Or similar accidents. They'd have to do quite a bit of hoop-jumping to turn that into a valid upload. Not something you can do by chance; if you are arguing that a maintainer could deliberately construct a package which didn't build, then... so what? > Same with missing build-depends. Those won't show up on the > maintainers system since he most likely has the depends installed all > the time. Many maintainers don't seem to have a clean chroot for > building stuff. Nor do several buildds. We only need _one_ in order to detect missing build-deps. The worse thing that we could possibly do is to build everything in a "clean" chroot. Build-conflicts are just as important as build-dependencies. > > Thirdly, this idea demonstrates a lack of understanding of what causes > > FTBFS bugs. It is emphatically _not_ the case that every package can > > be categorised as "does build" or "doesn't build". > > It eigther does build, does not build anymore or never did build. > Those last cases should be prevented. "Never did build" is already prevented. Everything which is uploaded to the archive has built at least once. "Does not build anymore" cannot reasonably be prevented, or even predicted. All we can do is detect it when it happens. > > Rather, what happens is that the package builds, or not, depending on > > a set of (usually complicated) criteria. These change over time as the > > rest of the packages in the archive change. Just because a package > > happened to build at a given time on a given system, does not mean > > that it will always build on all systems in the future. It's not all > > that unusual for a package to build on some of the buildds and fail on > > others. At this point the whole thing falls apart. > > Thats why I opt to include the versions of the debs in the build > environment. There are some scripts for it to generate them but afaik > even if one does (one has to do that in debian/rules iirc) they won't > be in the deb files. But at least the buildd log will show them. That's been pending for a long time, and it will be useful, but it will not solve the problem. Unless you include a complete snapshot of the build system, along with the hardware used (without observing it, or subjecting it to other outside influences - you've already violated the Heisenburg uncertainty principle by this point) then you can't guarantee what will happen. Instead, we simply deal with problems as and when they occur. It really isn't difficult. Certainly nowhere near as difficult as trying to enforce deterministic builds. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- |
Attachment:
pgp2upgUbUxwF.pgp
Description: PGP signature