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
>
>
Attachment:
signature.asc
Description: OpenPGP digital signature