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
signature.asc
Description: This is a digitally signed message part.
