Bug#948734: The package should be in contrib section

[Olek Wojnar]

Hi Paul and thanks (as always) for the explanation. (discussion
continued below)

On 1/12/20 11:04 PM, Paul Wise wrote:
> On Sun, 12 Jan 2020 21:42:53 -0500 Olek Wojnar wrote:
>
>> Could you please explain your rationale? The way I read Policy, I don't
>> see a problem. To clarify: the package is not installing via snap
>> because of a licensing issue that prohibits distribution (such as
>> Flash), that is just to prevent needless transitions in Debian [1].
> Policy states that "the packages in main must not require or recommend
> a package outside of main for compilation or execution" so a dependency
> on the snap at install time is not allowed.
>
> https://www.debian.org/doc/debian-policy/ch-archive.html#the-main-archive-area


Hmm, I always interpreted that as meaning a dependency on another .deb
package because of the "package" wording vs a word such as "component."
Furthermore, in Policy 2.2.1 it lists examples as "Pre-Depends, Depends,
Recommends" etc. which further implies the authors were thinking about
.deb packages. I also always saw the causality being along the lines of:
licensing prohibits inclusion in Debian (main) therefore a package must
be in non-free and .deb packages that depend on it must be in contrib
and potentially do install-time downloads of certain components (e.g.
Flash). I didn't see Policy applying to components outside of the Debian
distribution channels or the causality working the other way (i.e.
install-time download requiring contrib). Do you have any additional
insights as to the intent behind those words?


With that being said, and having thought about it some more, I agree
that the *intent* of Policy is possibly what you stated above. My
rationale being that install-time downloads have not been verified by a
DM/DD and could include software with problematic licensing that has
changed and not been appropriately reviewed. It that a valid concern? In
the interests of understanding Policy better, are there any other
aspects here that I'm missing?


I appreciate your time in this conversation! However it turns out, I
think that I may recommend an update to 2.2.1 to include things such as
Snap and Flatpak which were not prevalent when that section was first
written. Since those (and similar systems) are more and more common, we
should probably explicitly address the issue in Policy.


>> Nothing (except saving a LOT of work) prevents any of this from going
>> into main.
> Probably time to remove the package from Debian entirely then.


Well there's certainly no need for that since the Snap mechanism makes
it easy to transition existing users until such time as the packages get
more stable. But removal from Debian proper (main) may be necessary in
light of the above conversation.


-Olek



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20200120/6946f8bb/attachment.sig>