Hi! The discussion for #572253 has resulted in the following inclusion in policy (to be released as 3.8.5): > <p> > + For example, if a package <package>foo</package> is split > + into <package>foo</package> and <package>foo-data</package> > + starting at version 1.2-3, <package>foo-data</package> should > + have the field > + <example compact="compact"> > +Replaces: foo (<< 1.2-3) > + </example> > + in its control file. The package <package>foo</package> > + doesn't need any special control fields in this example, > + although would generally depend on or > + recommend <package>foo-data</package>. > + </p> i.e. the example of "what to do when you split a package" only mentions that foo-data should have a versioned-Replaces on the pre-split packages. The discussion in #578854, however, seems to indicate that the preference is actually to use both a versioned-Replaces _and_ a versioned-Conflicts in this situation. Is my reading of the discussion in #578854 wrong? or would the following be a better example to include? Conflicts: foo (<< 1.2-3) Replaces: foo (<< 1.2-3) Changing the example to this would mean that the example is in the wrong section and should appear in §7.6.2 not §7.6.1. We're clearly diverging from the original intent of the patch that was applied for #572253 here. I guess this is symptomatic of #578854 where clearer wording for the Conflicts section is discussed. But it looks to me like conflicting advice in #578854 vs #572253 needs to be ironed out in any case. (If I had looked only at policy about how to split a package and not at #578854, what example would I be likely to copy into $package? If I've missed the point of these discussions and these two are _not_ conflicting in their advice, then that's also an indication that the wording really needs to be clarified because they sure look like they do.) It also occurs to me that a concrete example of "how to split a package" like this is really good to have, but by the time it needs considerable explanation and additional fields added, it may actually start to distract from the purpose of policy and perhaps should be in dev-ref... but that's a completely different discussion again. regards Stuart (Please Cc me as I'm not subscribed to the bugs/lists in question) -- Stuart Prescott www.nanoNANOnano.net
Attachment:
signature.asc
Description: This is a digitally signed message part.