Re: Binaryless uploads [Was: FTBFS: architecture all packages]
Op ma 18-08-2003, om 04:38 schreef Joe Wreschnig:
> > > 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).
Then what are you suggesting? I don't see how we could avoid that.
> > 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).
3. Architectures being out of sync. Which is a special case of 1., but
hard to predict or to anticipate, and not always the maintainer at
fault. Being out of sync could mean there's still an older version in
the archive for a specific package, but it could equally well mean that
between the time you upload your package and the time it gets built, a
new package with slightly different semantics has been uploaded. Think
bison, flex, automaken; but it doesn't have to be that drastic.
> 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.
Yeah, but 11 buildd machines (one for every architecture) would try to
build it, and fail. That's a waste of precious CPU cycles.
And no, there's no way to prevent that, for a simple reason: It takes a
buildd admin to decide why the build failed. Assuming all architectures
are in sync, by the time the first buildd admin decides other
architectures will fail too, it's already too late. Just for the record:
usually all architectures are mostly in sync, except right before the
freeze, when an architecture has hardware problems, or when an important
library has porting issues; but those aren't the rule, they're
exceptions.
> Plus, I would like to think that most maintainers
> are smart enough to try building their packages at least *once* before
> uploading them.
rotfl.
> 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.
It would solve one problem at the expense of creating another.
> > 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.
Actually, it does. I'd like to see a suggestion from you where
* The buildd's aren't linked as "tight" to the archive as you suggest
they are.
* The buildd's are still able to compile packages against *current*
unstable. Not that of yesterday, not that of two weeks ago, that of
*today*.
Until you can come up with one, I suggest you leave everything as it is.
> 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.
Correct. Still, you're assuming an environment that does not change,
which is an incorrect assumption.
Let me give you a real-life example: When I first uploaded doc-linux-nl
-- an arch:all package -- I made sure the build-dependencies were
correct, by using pbuilder. As such, when I uploaded the package,
everything worked perfectly.
However, a few months later, I received a bug report that the package
didn't build from source. Surprised, I tried building it under an
up-to-date pbuilder chroot, and found out that, indeed, it didn't build
anymore.
What had happened? The dependencies of one of my build-dependencies had
changed, modifying one package which was depended on (groff) into a
recommends. As such, since I did use the functionality provided by
groff, the package did not build from source anymore. The fix,
obviously, was to add groff to the build-depends, rebuild, and upload.
Your suggestion will *not* prevent such things from happening again: at
the time my package was uploaded, everything was perfectly allright, so
would you have tried to build it before it could've gone into the
archive, you wouldn't have any problem. However, would I not have
received this bugreport, the package could have gone into stable,
unbuildable.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"An expert can usually spot the difference between a fake charge and a
full one, but there are plenty of dead experts."
-- National Geographic Channel, in a documentary about large African beasts.
Reply to: