Re: 2013 sometimes still feels like 2003 or 1993 (Re: NEW processing during freezes
Hi,
On 04/05/13 at 10:10 +0100, Wookey wrote:
> +++ brian m. carlson [2013-05-03 21:39 +0000]:
> > On Sat, May 04, 2013 at 12:10:25AM +0300, Timo Juhani Lindfors wrote:
> > > "Bernhard R. Link" <brlink@debian.org> writes:
> > > > Once we drop that and only give people the right to modify the
> > > > software we distribute but no longer the possiblity to do so
> > > > on their own, the "Free" we are so proud on gets mood.
> > >
> > > Doesn't pbuilder make it easy enough for anyone to modify and build the
> > > software on their own?
> >
> > The issue with sterile build environments is not just for building
> > packages for normal use. If I'm fixing a bug in a package, I may need
> > to build that package several times, testing different fixes. If
> > everyone assumes that packages will be built in a sterile environment,
> > nobody will care that their packages don't build twice in a row,
>
> This is a good point. I've been doing a lot of building of stuff
> (mostly the core/base ~200 packages) with small fixes recently and
> it's clear that 'doesn't build a second time' is increasingly common
> (and very annoying). This is a result of maintainer's workflows never
> doing this, I presume. As Russ said - if it's not tested it probably
> doesn't work.
>
> I am huge fan of both building in clean environments _and_ being able
> to build twice. I don't think there is any solution to this other than
> testing it in an automated fashion. An sbuild or pbuilder option for
> --build-twice would make testing a very simple matter.
>
> Does policy say anything about this? Can it in fact be deemed FTBFS if
> it fails the second time? I think it should.
I worked on archive-wide tests of double-builds a long time ago. Hacking
sbuild to do that was quite easy (patch available at
http://anonscm.debian.org/viewvc/collab-qa/debcluster/configs/sbuild-twice.patch?view=log
for an ancient version of sbuild). Our amazon 'Debian QA' credits could be
used to perform such tests if someone is interested but doesn't have the
required rebuild infrastructure. Note that it should also be tested
whether the resulting packages are identical (FSVO identical).
Now, I'm not so sure that we should spend developer time to (1) find
those issues and file bugs; (2) fix those issues. I personally find it
easier to create a temporary git repository and to use git clean / git
checkout to return to a pristine environment.
Lucas
Reply to: