If the issue is to prevent broken reverse dependencies when a package is updated a solution could be to use a continuous integration system. The reverse dependencies would be rebuilt automatically when the package is updated, and the errors reported on the mailing list.
If possible I would to that at the SCM level, such that errors are detected before the package is uploaded. At Apache we use Gump [1] to do that and it provides a very useful feedback. How to do that properly with Debian packages is a tricky question though. Emmanuel Bourg [1] http://gump.apache.org Le 25/04/2013 17:56, Niels Thykier a écrit : > Hi, > > As the topic suggests I want to talk about improving the situation on > auto-generating versioned dependencies via our helper tools (e.g. > javahelper and maven-*-helper). > > At the moment, javahelper doesn't add versioned dependencies, which is > actually really bad. I am not sure what the situation is in the maven > helpers camp. If they don't add versioned dependencies, I think now > might be a good time to change that. > > I am therefore considering to make jh_depends (javatools) to generating > "$pkg (>= ${installed-upstream-version})" dependencies by default. > Given all the information available in the pom files, the maven helper > tools may be able to give better (i.e. less "pessimistic") lower bound. > > On a related note, would it make sense to deploy something like "shlibs" > files for Java? I have experimented with adding "symbols" files in the > past and they tend to be rather large if every symbol must be covered. > Though if we reduce the granularity from symbol level to "class" or > (Java's) package level it might be more feasible. > > ~Niels > >
signature.asc
Description: OpenPGP digital signature
