[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: FTBFS: architecture all packages



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.

> 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?

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.

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.

> 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.

> 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.

MfG
   Goswin



Reply to: