Hey list, Guillem and I were discussing a design issue I was having today with an upstream package. There may be various workarounds, but I think the scenario I am confronted with may have presented itself to others. I believe I may have a generalized solution I would like to propose for peer review. Currently under DPM § 7.2 packages may contain a Recommends stanza in their d/control files: "This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations." Consider the scenario where there may be a package A that recommends a package B (say, a local database instance instead of a remote one). Perhaps A is a system service that does not require B. But if B is configured A may need to do something during its postinst hook as a convenience to leverage B immediately. The problem, however, is that if B was selected for installation at the same time as A then there is no guarantee that B will be configured prior to A. I propose a Pre-Recommends stanza. It would be a blend of Depends and Recommends such that anything listed in Pre-Recommends that is selected for installation must be configured first. In other words it allows for ordering constraints on a soft dependency. Thoughts? -- Kip Warner | Senior Software Engineer OpenPGP signed/encrypted mail preferred https://www.thevertigo.com
Attachment:
signature.asc
Description: This is a digitally signed message part