Re: Draft spec for new dpkg "triggers" feature
Joey Hess writes ("Re: Draft spec for new dpkg "triggers" feature"):
> If dh_scrollkeeper had always behaved like you wish it had, then it
> would currently be adding a dependency on scrollkeeper (>= 0.3.8). Once
> debhelper is updated to add a dependency on the new scrollkeeper that uses
> triggers, all the packages using dh_scrollkeeper will need to be rebuilt
> to get the new dependency. The only way to gurantee that the right
> dependency is added will be to build-depend on the relevant version of
> debhelper. The current and past behavior of dh_scrollkeeper has no
> bearing on this.
But ideally the right dependency is something like
Breaks: scrollkeeper (< first-triggers-interested-version])
if we have Breaks by then or failing that nothing at all.
Really, we want all of the gnome packages not to depend on
scrollkeeper so that people can remove scrollkeeper if they want.
except that I think we don't have Breaks in Debian yet.
Joey Hess writes ("Re: Draft spec for new dpkg "triggers" feature"):
> This looks like a very good design, although I will need to think about
> it some more (and revisit how rpm handles triggers) to post anything
> general about it. For now I'm limiting my comments to debhelper-related
> aspects.
I haven't looked at rpm's approach at all, I confess.
> Ian Jackson wrote:
> > 3. Update debhelper's dh_scrollkeeper not to edit maintainer
> > scripts. dh_scrollkeeper should also issue a warning if it finds
> > scrollkeeper (>= 3.8) in the Depends control file line.
>
> Actually, lintian should issue such a warning. Debhelper is not intended
> to find packaging problems.
Right.
> > However, dh_scrollkeeper doesn't generate the scrollkeeper dependency
>
> This is not a design problem in dh_scrollkeeper. It's not always
> appropriate for a package that ships gnome documentation to depend on
> scrollkeeper, and things will work without the dependency, with
> scrollkeeper noticing the previously installed documentaton if/when it
> is installed.
The correct answer would have been for dh_scrollkeeper to have written
${dh_scrollkeeper:Depends}. Then each package could have decided
whether to put the dependency in Depends, Recommends or Suggests.
The ugly messages from dpkg-gencontrol are just a bug.
> If the new design called for all packages that trigger scrollkeeper to
> depend on the new version of scrollkeeper, dh_scrollkeeper could easily
> be changed to add that dependency through misc:Depends. Some packages
> that use dh_scrollkeeper will probably not have ${misc:Depends} in their
> control file, since some developers remove it due to the ugly messages
> that dpkg-gencontrol generates if it's empty. Such packages could be
> automatically detected and fixed.
As I say above, I think the right design is for the updated packages
not to relate to scrollkeeper at all.
Ian.
Reply to: