Ticket #1135 (assigned task)

Opened 9 years ago

Last modified 7 years ago

Punt the hacky metapackages used only in build dependencies

Reported by: geofft Owned by: vasilvv
Priority: normal Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:


sbuild 0.63.0-1 (in git, unreleased) drops the 'internal' dependency resolver, which we've been using for a while, and has various limitations including the lack of handling or-gates in build-dependency lines (necessitating a few metapackages only used internally as build dependencies). The 'apt' and 'aptitude' resolvers create dummy packages with the Build-Depends line as the Depends line, and attempt to install that, providing more flexible build-dependency handling. In theory there should be no regressions, but it would be good to check that.

Change History

comment:1 Changed 9 years ago by geofft

I can't decide whether we should drop those hacky metapackages and require use of the apt/aptitude resolver once our build server is running a version that provides it (squeeze-backports should work). On the one hand, this means that sbuild on an older release won't work; on the other hand, I expect nobody to do that, and instead to run debuild or something and install (and resolve) build-deps by hand.

Certainly we should drop them once every release we support has a new enough sbuild but that'll be a while (after Lucid and Squeeze are both desupported, so summer 2015).

comment:2 Changed 8 years ago by jdreed

sbuild 0.62.6 (in precise, which we're using on magrathea) defaults to the 'apt' resolver, so the quantal rebuild will test that there are no regressions. We can then move forward on testing and dropping the conditionals, though I'm not sure how best to do that? Probably we should just rebuild precise into -bleeding or something.

comment:3 Changed 8 years ago by jdreed

debathena-cups can die, because Hardy is dead.
debathena-libreadline can die, because libreadline4-dev is no longer a thing, and libreadline5-dev is >> 5.1 in all things we care about.
debathena-maybe-krb4-config should die, because krb4.
I think debathena-libss can die because there should be nothing alive still running our libss (right?)

That leaves:

  • gdm
  • syslog
  • maybe-apparmor
  • maybe-ubufox

We still need the maybe packages, right, because a resolver won't help with build-depend-if-exists?

comment:4 Changed 7 years ago by jdreed

  • Owner set to vasilvv
  • Status changed from new to assigned
  • Summary changed from Test-rebuild the archive with the 'apt' or 'aptitude' sbuild build-dep resolver to Punt the hacky metapackages used only in build dependencies

Assigning to Victor, since this is relevant for Victor's rebuilding of the archive.

I think we cannot kill debathena-gdm, can kill debathena-syslog, and cannot kill the maybe packages.

comment:5 Changed 7 years ago by jdreed

In particular, we should kill debathena-ssh-server and debathena-ssh-client.

The former is particularly pointless:
ssh-server-config Build-Depends: debathena-ssh-server | openssh-server (>= 1:4.3) | ssh-krb5

However, debathena-ssh-server Depends: openssh-server (>= 1:4.3) | ssh-krb5

comment:6 Changed 7 years ago by andersk

There’s that, and there’s the fact that ssh-krb5 has been a transitional package since etch. (This did actually make sense BITD, though, when sbuild ignored Build-Depends disjunctions, but they could still be used to satisfy them locally if they happened to be installed.)

Note: See TracTickets for help on using tickets.