[Debian-med-packaging] Your upload of relion has a depencency to nvidia-cuda-toolkit and will not be accepted in main

[Andreas Tille]

Hi Roland,

On Wed, Sep 30, 2020 at 01:57:39PM +0200, Roland Fehrenbacher wrote:
> Hi Andreas,
> 
>     A> Hi Roland, thanks a lot for your update of relion.  A minor issue
>     A> is that the changelog mentiones version 2.1-1 which was never in
>     A> Debian (since rejected by ftpmaster).  I personally would have
>     A> integrated those changes in your new upload - but may be that's a
>     A> matter of taste.  BTW, is there any reason you are using 3.1.0-2
>     A> instead of 3.1.0-1?
> 
> I uploaded 3.1.0-1 and later added an autopkgtest in 3.1.0-2.

Cool you added the test but this is not reflected in the changelog.
Moreover I think its a good idea if we could find every package that
claims to be uploaded to unstable at snapshots.debian.org (which is not
the case for 2.1-1 and 3.1.0-1) and a paragraph will mention all changes
between the latest upload and the current one.
 
>     A> But now to the real issue: Relion
> 
>     A>    Build-Depends: nvidia-cuda-toolkit
> 
>     A> And your control file has
> 
>     A>    Package: relion-cuda Section: contrib/science
> 
>     A> It is not possible to have a source package in main
>     A> Build-Depending from a non-free package and creating a binary
>     A> package in contrib.
> 
> Can you give me a reference for this rule?

I admit I'm to lazy to seek any documents for this.  However, that rule
is pretty simple.  Everything in main is official Debian and nothing
else.  So you can not build current relion with official Debian (since
you are Build-Depending from "something else") neither are all your
build targets part of official Debian.  This is simply not permitted
(and I'm pretty sure its documented somewhere).

> We had a discussion about this
> point when I did 2.1, and the way I did it now, was the suggested way at
> the time.

I'm pretty sure I didn't took part in this discussion or alternatively I
was not clear in my mind.  I would never have something else than above
if I would have understood the intention.
 
>     A> IMHO you need to split this up into two source packages:
> 
>     A>    1. one that builds with packages in main and creates packages
>     A>       in main exclusively
> 
>     A>    2. one source package that can include packages from non-free
>     A>       and issue binary packages to contrib or non-free
> 
>     A> The current upload to new will receive a reject
> 
> For 2.1 I got a reject because of missing license entries, but not
> because of the main/contrib mixing.

It might be that ftpmaster was simply stumbling upon that license
entries and did not kept on reading.
 
>     A> (may be you ask for rejection to save some time).
> 
> No idea how I could save time by getting a rejection :)

You save time of ftpmaster when you ask for a rejection directly instead
of letting them inspect the package and reject it afterwards.  Moreover
you can upload right now a fixed package and save time for another cycle
in the new queue.

Kind regards

        Andreas.

-- 
http://fam-tille.de