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

Re: Challenge: Binary free uploading

On Sun, Jul 16, 2006 at 04:47:12PM +1000, Anthony Towns wrote:
> Hi all,
> At https://wiki.ubuntu.com/NoMoreSourcePackages is a description of
> the new world order for Ubuntu packages -- which will simplify making
> changes to Ubuntu packages to a matter of simply committing the change
> to the source repository with bzr, and running a new command something
> like "src publish edgy" to instruct the autobuilders to grab the source
> from the bzr repository, create a traditional source package, and start
> building it for all architectures.
> We've recently seen an example of someone using some general features of
> the bug tracking system to mirror LaunchPad's features wrt tracking the
> status on other BTSes [0] -- what I'm wondering is if we can't manage to
> hack up a similar feature to that one for Debian with our current tools.
> The idea would be, I guess, to be able to setup pbuilder on a server
> somewhere,

Why pbuilder? It's a great tool to check build-deps, and it's a great
tool to casually build packages from time to time; but if you're really
going to get rid of binaries in uploads, I think the more efficient way
to do so would be to hack sbuild and buildd to do so.

> have it watch for a build instruction -- and then automatically
> check out the source, run a build with pbuilder, make the build log
> available, and if the build was successful, make the .changes file, the
> source and the binary packages available, so that they can be checked by
> hand, and uploaded to the archive. 
> For bonus points, have the server be able to automatically do the upload
> by the maintainer downloading the changes, signing it, and sending the
> signed changes file somewhere.

buildd already has all that.
* wanna-build has lists of packages that need to be built, and buildd
  grabs packages out of those lists. The wanna-build database is
  currently fed by some scripts that are part of dak, but there's
  nothing preventing anyone from writing different scripts and/or
  modifying wanna-build slightly.
* build logs are on buildd.d.o.
* .changes files are part of the build log, and are clearly marked so
  they can be mechanically extracted by a sed one-liner (possibly a perl
  one-liner too, not sure about that bit).
* uploads are done by sending signed .changes files to the buildd host
  (the exact mail address to be used depends on the exact buildd host in
  use, obviously).

You would only need to create some scripts to populate the wanna-build
database, plus modify sbuild so that it knows how to fetch a source
package from a version control system rather than from a Debian mirror.
The rest would probably work as is.

All that being said, I'm not convinced doing sourceless uploads is
actually a good idea. It's been proposed in the past, but I've never
seen arguments that convinced me it would be a good idea. The difference
with this idea is that you could set it up so that the original binary
upload would be done out of your source repository, which would then
do a sourceful upload to ftp-master which in turn would trigger builds
on other architectures; that way, you wouldn't bother other
architectures with untested builds.

But we'll still have issues.

For starters, we'd need a *lot* of hardware to be able to do all these
builds. Many of them will fail, because there *will* be people who will
neglect to test their builds, and they will hog the machine so that
other people (who do test properly) have to wait a long time for their
build to happen.

Ubuntu has a lot more money behind them than Debian does, so they can
mitigate this problem by simply buying more hardware. How do you suggest
Debian would tackle this problem?

Fun will now commence
  -- Seven Of Nine, "Ashes to Ashes", stardate 53679.4

Reply to: