Roger Leigh writes ("Re: re buildd's resolver and package's build deps"):
> Taking one of php5's dependencies as an example:
>
> libdb-dev (>= 4.7) | libdb4.8-dev | libdb4.6-dev
>
> This dependency permits building against no less than *three* different
> Berkeley DB versions. Given that these versions are typically
> incompatible, imagine if a new upload caused a version change. It
> could break all existing databases when the user upgrades and they are
> no longer readable. If could even be a downgrade. The same applies
> to any other libraries.
Packages are not only built as part of our own efforts to make the
Debian distro as we have it on our own archive site.
They are also built by users, by our downstreams, etc. The
build-dependencies are important for these people too, and they are
better served if we include the alternative dependencies (even if we
don't test them very well).
> I would recommend keeping backports on a separate VCS branch rather than
> having a single unified package. It keeps things which should be
> separate, separate, and will give unambiguous results for each suite.
> It also makes which suite needs which dep self-documenting, and old
> deps will not make the current version untidy and potentially buggy.
This is IMO not the right approach. Because users will want to
download the source code to our packages and build it in ways we don't
anticipate. Backports is only one example; forward ports, ports to
other distros, etc., are others.
Ian.
--
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/19811.61581.58514.139...@chiark.greenend.org.uk
