Re: Proposal for new version mangling rule when ML-Policy takes effect
Hi Andrius and other team members,
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.
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.
They are compatible to Debian's common practice.
[1] https://salsa.debian.org/deeplearning-team/ml-policy/-/blob/master/ML-Policy.pdf
On Fri, Oct 09, 2020 at 08:47:12AM +0300, Andrius Merkys wrote:
> I agree that marking packages affected by ML-Policy would be beneficial,
> however, I am not sure that version mangling rule is the best way to do
> so. Consider an example case where upstream tarball has to be repacked
> to exclude both non-DFSG and ToxicCandy contents. In this case suffix
> "+dfsg" would be preferred over "+mlp" due to its stronger meaning, thus
> losing ML-Policy marker altogether.
>
> Christian's suggestion of XS-ML-Policy field for d/control looks more
> appropriate to me. Although I think ML-Policy marker should belong to
> d/copyright alongside Files-Excluded and Disclaimer fields.
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.
Reply to: