Ian Jackson wrote:
> I haven't looked at rpm's approach at all, I confess.
Well, you didn't miss much.
http://www.rpm.org/support/RPM-Changes-6.html
To quickly summarise, it's backwards to your design in that the
triggered package defines the trigger, which can be something like
"installation of package X, Y, or Z". There are some complications like
versioned package dependencies in triggers.
> 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.
That doesn't scale very well, requiring users to edit debian/control as
well when editing debian/rules. I've considered making the dependency
addition configurable (on a per subpackage basis of course) with a
switch. It looks like with triggers, I'll instead be able to remove most
of it.
> As I say above, I think the right design is for the updated packages
> not to relate to scrollkeeper at all.
Aside potentially from the upgrade issue..
--
see shy jo
Attachment:
signature.asc
Description: Digital signature