Re: FTBFS: architecture all packages
Andrew Suffield <asuffield@debian.org> writes:
> On Tue, Aug 19, 2003 at 09:12:02PM +0200, Goswin von Brederlow wrote:
> > Andrew Suffield <asuffield@debian.org> writes:
> > > > > 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.
> >
> > I've seen packages with broken rules files or broken Makefile and even
> > missing files. And don't tell me the previous gcc version didn't need
> > a *.c file of the source but the new one suddenly does.
>
> I severely doubt you are accurately describing what happened here.
Not in the webmin case. Thats just broken source form the start.
But I have seen it happen for other sources. True, most such instances
won't happen anymore because autobuilders will catch them. But again,
not for binary-all or binary-arch.
> > > > 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?
> >
> > If its hoop-jumping then it must be intentional. Point is it happens.
>
> Who cares? We cannot build an automated system here that will be able
> to stop people doing things like that.
But we can crosscheck the DDs build by a buildds build. Doesn't realy
harm, its only a very few and usually very easy to build packages that
we talk about.
> > > > > 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.
> >
> > Experience has proven you wrong. Shit happens.
>
> Bullshit. Provide an example of a package which the maintainer
> uploaded (note, this includes binaries) and which has never been
> built, or go away.
You can go and check the BTS yourself. I've seen it happen and
reported it, afaik all binary-any packages. That was way before the
buildds which greatly reduced the amount of packages this can happen
too.
But who is to say that the same thing won't or doesn't happen to
binary-all or binary-arch packages?
There is also another reason, not mentioned before, for source only
uploads. It takes way less bandwith to upload a diff.gz+dsc file than
to upload a big binary package.
MfG
Goswin
Reply to: