What's needed to integrate backports at full scale
[ Moving to -devel for a more technical discussion, please respect
reply-to ]
On Sat, 14 Apr 2007, Christoph Haas wrote:
> (1) Packages depend always on the newest other package versions
>
> Most of the time the (automatically calculated) dependencies of packages
> that go into unstable are on other packages from unstable. Users on the
> stable distribution can't use it because e.g. libraries on their system
> aren't new enough to satisfy the dependencies. The obvious solution is
> backports. But most of the time the dependency doesn't have to be that
> strict. Do you really need a libc6 of version 2.3.6 or is >=2.1 good
> enough? Most packages aren't available as backports so the user would
> obviously dist-upgrade to "testing" or "unstable" thus ruining the
> rock-stableness of the system. Some maintainers deliberately maintain
> the dependencies manually so their packages can be used on a stable
> distribution. Can't every maintainer do that? (Serious question. I'm not
> sure if/how that's technically feasible.)
The automatic dependency are mostly right and they are not a problem
if a simple recompilation replaces them with a dependency that
works within stable.
However as you know, there's rarely something like "simple recompilation"
to backport a package because:
(1) the build-dependency require a package which is not in stable
(2) the generated package depends on packages which are not in stable
Concerning the first point, either the missing build-dependency is
inavoidable and then we need to backport this build-dependency or this
build-dependency is too strong and could be replaced by something else
available in stable. Obviously, we want to backport as few packages as
needed so we should avoid backporting packages if the build-dependency is
too strong.
IMO this means that we need to add some extra information in the
build-dependencies probably with some new fields. Either we make
it possible to have different build-dependencies for each release
or we introduce a concept of "minimal build-dependency" vs "wanted
build-dependency". Unstable buildd would use the latter while backport
buildd would use the former.
Example with release-specific build dependencies:
Build-Depends: perl (>= 5.8.0), libmysqlclient15-dev
Sarge-Build-Depends: perl (>= 5.8.0), libmysqlclient12-dev
A buildd would first use <codename>-Build-Depends and fallback to
Build-Depends if there are none.
Example with min/wanted build dependencies:
Minimal-Build-Depends: perl (>= 5.8.0), libmysqlclient-dev
Build-Depends: perl (>= 5.8.0), libmysqlclient15-dev
In this case, the minimal build depends avoids explicitely any
release-specific dependencies to provide a working build depends for as
many cases as possible (although it provides less control against which
version it's going to be built and so on).
Concerning point (2), this could be solved with britney. The "backports"
section would be generated from a "proposed-backports". Developers upload
to proposed-backports and buildd build in that environement.
How does that sound?
My preference goes for the release-specific build-depends. If you combine
to this the export of a variable TARGET_RELEASE, then you have the
possiblity to tweak the behaviour of debian/rules based on the target
release and we effectively have the possibity to maintain backports
and unstable packages in a single branch. Probably that bigger packages
would require different branches, but for many small packages this
possibility would be really interesting IMO.
I'm interested in comments from people who have made many backports and
from people who are maintaining big (suite of) packages.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: