Ticket #875 (closed enhancement: fixed)

Opened 10 years ago

Last modified 9 years ago

nobuild files should live in svn

Reported by: jdreed Owned by: jdreed
Priority: normal Milestone: Precise Alpha
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

The "nobuild" files should live in svn somewhere, and dasource should copy them to the right location.

Change History

comment:1 Changed 10 years ago by jdreed

Actually, if we're going to make changes, I think I'd rather have a master nobuild file that lives somewhere, where each line has a packagename followed by a list of codenames not to build for.

Thoughts?

comment:2 Changed 10 years ago by geofft

Brilliant idea: what about adding something like (Build-)Depends: base-files (>= 5.0.0) or whatever to debian/control, and having da check satisfiability before it tries to build the package in question?

Actually, having da check satisfiability of the actual dependency (like, cups (>= 1.1) or whatever) might also work.

comment:3 Changed 10 years ago by jdreed

OK, here's my proposal:

  • Add XSBC-Debathena-Support-Level: to the control.in files, with the following values: cluster, graphical, standard. (I think we can maybe getaway with just XS-? Users don't need to see this.)
  • dasource checks this, and checks a master file somewhere of what releases have what level of support. It then creates a nobuild file for the releases that don't have this level of support. (The nobuild file would get clobbered and recreated with each dasource invocation).

So, for example, debathena-cluster-login-config has XSBC-Debathena-Support-Level: cluster. cluster is only supported for lucid and natty right now, so a nobuild file gets created, and every releases other than natty and lucid is listed there.

We may also want to consider supporting buildfor files that whitelist releases, and if a directory contains both buildfor and nobuild then sbuildhack errors out.

comment:4 Changed 10 years ago by jdreed

So, we talked a bit more about this at release-team. We determined that in fact we're not really using "nobuild", we're abusing it to get a "buildonlyfor" functionality. I think my previous proposal of metapackage-based support levels is probably too complex, but I do like the feature of dasource dealing. OTOH, we want to get rid of dasource. So the right thing here is probably to do something like:

XSC-Debathena-Build-For: lucid natty

and sbuildhack and daupload (which currently check the nobuild files) instead check for that. We can also support XSC-Debathena-Nobuild:, and have it be an error to have both in a control file. They'll also appear in the changes file, which daupload can check.

comment:5 Changed 9 years ago by jdreed

Now that #913 is deployed, we can fix the packages that currently make use of nobuild files:

./athena/debathena-nmh/nobuild
./third/schroot/nobuild
./config/debathena-cluster-login-config/nobuild
./config/debathena-reactivate/nobuild
./config/debathena-tex-config/nobuild
./config/debathena-cluster-cups-config/nobuild

comment:6 Changed 9 years ago by jdreed

c-l-c and tex-config in r25508.
reactivate in r25507
Skipped cluster-cups-config because we don't care

Don't know what we should do for third/schroot and debathena-nmh. I can't remember why we have the former, and I think the latter is a natty-and-later package, yes?

comment:7 Changed 9 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed
  • Milestone changed from The Distant Future to Precise Alpha

comment:8 Changed 9 years ago by jdreed

geofft suggests schroot was only ever for intrepid/jaunty and we should stop caring about it (and possibly move it to attic?). We never had a cluster release on hardy.

comment:9 Changed 9 years ago by jdreed

  • Status changed from accepted to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.