On Sat, Sep 07, 2019 at 07:07:37PM -0700, Kip Warner wrote: > 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. An alternative is to have an 'After' field. It would not specify any dependency relationship between packages, only an ordering one. You'd have to specify a package in Recommends and After, but you could also specify it in Suggests and After, or just generically ensure your package is configured after some other package. It's more versatile, at the expense of more typing. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Attachment:
signature.asc
Description: PGP signature