Re: RFC: Packaging buildd
Simon Richter <email@example.com> writes:
> My idea is to have a web page with current "problems". A problem could be
> a package not building, an uninstallable package, etc. The layout will be
> much like the BTS, just that the only method to get rid of a "problem" is
> to solve it (i.e. there is no "close" command"). Porters can then go
> through the list of problems for their arches, write bug reports etc. The
> buildds can also try to address problems in their idle time (for example,
> ignore the build dependencies and build in an auto-apt environment, or do
> an arch-specific rebuild).
In addition to this, have you considered adding support for periodic
rebuilding of existing packages e.g. when buildd is idle?
To address the problem of newer builds of the same version, you could
get buildd to put the build number as a suffix, which will be able to
vary on each arch (not included in dependencies). For example,
4.3.0-1#1 will be the first autobuild of version 4.3.0, debian version
1, then 4.3.0-1#2 will be the second, etc.
This might be useful is a build fails due to a Build-Dependent package
not working, producing a broken deb. Thus you can just reschedule it
once the dependency is fixed.
** Registration Number: 151826, http://counter.li.org **
Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/
GPG Public Key: 0x25BFB848 available on public keyservers
To UNSUBSCRIBE, email to firstname.lastname@example.org
with a subject of "unsubscribe". Trouble? Contact email@example.com