On Sun, 2003-08-17 at 20:57, Andrew Suffield wrote: > 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. Under the current system. I'm envisioning one where the buildds aren't tied so closely to the archive, and so it won't enter the archive until it's been built by at least one (or possibly all that it claims to support). > 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. > > 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". What causes FTBFS bugs now: 1. Bad Build-Depends. 2. Broken code that doesn't port (either to another architecture, to something that's not the maintainer's home directory, whatever). All of 1 and many of 2 would be solved by binaryless uploads. A new type, "maintainer never tried to build package ever (and so debian/rules has a syntax error or debian/control has a bad version or whatever)" would be introduced - but such packages would be blocked from entering the archive anyway. Plus, I would like to think that most maintainers are smart enough to try building their packages at least *once* before uploading them. In this particular case (webmin), binaryless uploads *would* solve the problem. Since the webmin maintainer couldn't manually do whatever magic he does when he builds the package, he'd have to work it into the build scripts that the buildds - and users - use. > 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. Right. But I'm not talking about the current archive and buildd relationship, so it doesn't matter. If at any point a package doesn't build on an architecture that it a) used to, and b) still claims to, that's a bug. Both under the current system, and one of binaryless uploads. The change is how far they get before the bug is noticed. Currently they can make it all the way to testing, and maybe even stable. -- Joe Wreschnig <piman@debian.org>
Attachment:
signature.asc
Description: This is a digitally signed message part