Re: Proposal for new version mangling rule when ML-Policy takes effect

[Andrius Merkys <merkys@debian.org>]

Hello,

On 2020-10-09 16:21, Mo Zhou wrote:
> These feedbacks are very constructive. Based on our opinions, I think it
> is not necessary to put such an identifier to the mangled version
> strings. In fact, I find the string "ML-Policy" is already a very good
> identifier if we do a code search:
> 
>   https://codesearch.debian.net/search?q=ML-Policy
> 
> So the preliminary revision to ML-Policy may look like this:
> 
> (will be appended to Sec.4 [1])
> 
>   8. [Identifier] Packages effected by ML-Policy *must* include the
>      "ML-Policy" string in the "Disclaimer:" field of `debian/copyright`.
> 	 Additionally, it is *recommended* to clearly annotate the
> 	 corresponding changes. They will be helpful when revising ML-Policy
> 	 or double-checking.

I guess this should be fine for the time being if we are OK with rare
false-positives (some code in some package may refer to ML-Policy
without actually be cleaned according to it).

>   9. [Version-Mangling] Version strings of packages with some ToxicCandy or
>      NonFree contents being filtered due to ML-Policy should be mangled
> 	 following the common "+dfsg" convention.

I am not sure that removal of ToxicCandies should be marked with
"+dfsg". ToxicCandies by definition are DFSG-compliant. I would suggest
using "+ds" for packages where only ToxicCandies are excluded, as
tarballs containing them actually are DFSG-compliant, but not
MLP-compliant. Thus I would probably rephrase it as follows:

  9. [Repack-Suffix] Version strings of packages with some ToxicCandy or
     NonFree contents being filtered due to ML-Policy should contain
     appropriate suffix according to the common practice (e.g.,
     "+dfsg"or "+ds").

> XS-ML-Policy sounds fantastic. But I'm not sure whether it involves
> changing the apt/dpkg code? I think we'd better avoid touching these
> code at the current stage.

This is worth investigating. For time being [Identifier] should be
sufficient, but in future it would be nice to have more structured means.

Thanks a lot for bringing this up!
Andrius