[ 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
