Bug#948734: The package should be in contrib section

[Paul Wise]

On Mon, 2020-01-20 at 12:33 -0500, Olek Wojnar wrote:

> Hmm, I always interpreted that as meaning a dependency on another .deb
> package because of the "package" wording vs a word such as "component."

I always interpreted it in the general sense rather than in the sense
of a dependency on Debian packages, mainly because of this sentence:

   None of the packages in the main archive area require software
   outside of that area to function.

> 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).

Your package does install-time downloads of certain components and
isn't in any way useful without those downloads, so the only difference
between your case and that of Flash is the licensing of the download.

> Do you have any additional insights as to the intent behind those words?

Debian has always required downloader packages go to contrib, but
I don't see anything in the ftp-master reject FAQ about this:

https://ftp-master.debian.org/REJECT-FAQ.html

> 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?

As far as I know Debian main was always meant to be self-contained and
downloader packages violate that constraint. The possibility of
problematic licensing is just one aspect of a non-self-contained
archive, you could also have source code disappear or malware added,
but if you have a mirror of Debian main that you do not change, then
these things generally cannot happen.

> 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.

I don't think it would be a good idea to list specific technologies in
Policy since there is always the possibility of other technologies
existing and the ones you list becoming less popular. I agree that the
wording could use a slight clarification to state that Debian main must
be entirely self-contained and that any dependencies on content of any
kind outside of Debian main are not allowed.

Please ask the Debian ftp-masters to mention this in the REJECT-FAQ.

> 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.

As I have said above, I think the Snap package is a violation of Debian
policy due to requiring things outside of main. You could of course
move the Snap-depending package to contrib as a workaround until you
can return a proper Debian package back to main.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://alioth-lists.debian.net/pipermail/pkg-games-devel/attachments/20200121/0d0b380b/attachment.sig>