Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-10-01 Thread Roland Fehrenbacher
> "S" == Samuel Thibault  writes:

S> Roland Fehrenbacher, le mer. 30 sept. 2020 20:47:58 +0200, a
S> ecrit:
>> Is the only solution here then really to have two source packages
>> with exactly the same upstream source and only a difference in
>> the way the binaries are built and what they depend upon?

S> That's what I do with starpu and hwloc. In starpu the packaging
S> difference is really minimal so I use some sed scripts to switch
S> between the "main" version and the "contrib" version. In hwloc
S> the difference is more involved so I use two branches, and just
S> pull from master to contrib. In the end it's not really much
S> additional work.

Thanks Samuel, such examples were exactly what I was looking for. I will
take the 'two branches' approach. Seems that's the cleanest ..



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Paul Wise
On Wed, Sep 30, 2020 at 10:11 PM Richard Laager wrote:

> I would expect that:
>
> 1. main builds include main repositories
> 2. contrib builds include main, contrib, & non-free repositories
> 3. non-free builds include main, contrib, & non-free repositories

AFAICT, we don't use separate chroots for building
main/contrib/non-free right now. I'm also not sure that running
non-free software on the buildds for main (even in a chroot) is a good
idea.

> Am I missing something here? If I'm understanding everything correctly,
> this seems buggy.

AFAICT you aren't missing anything and I agree the current situation is buggy.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Richard Laager
On 9/30/20 4:45 PM, Paul Wise wrote:
> The
> official buildds, for packages in main, seem to include contrib but
> not non-free binary packages in the chroot's apt sources.list files.
> Both contrib and non-free source packages are available in the chroots
> apt sources.list files. This appears to be the same for all three of
> main, contrib, non-free.

I would expect that:

1. main builds include main repositories
2. contrib builds include main, contrib, & non-free repositories
3. non-free builds include main, contrib, & non-free repositories

This would match the Policy allowed package dependencies.

Including _more_ than this wouldn't break builds, but could allow
non-Policy compliant dependencies to sneak in. For example, a package in
main that Build-Depends on a package from contrib should FTBFS on the
buildd, but would not.

Including _less_ than this could break builds. For example, if I have a
"free package in contrib that require[s]... non-free packages" (Policy
2.2.2) and the buildd doesn't include non-free, it will FTBFS when it
should build.

Am I missing something here? If I'm understanding everything correctly,
this seems buggy.

-- 
Richard



signature.asc
Description: OpenPGP digital signature


Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Paul Wise
On Wed, Sep 30, 2020 at 8:48 PM Philipp Kern wrote:

> Somewhat ironically not depending on anything but main is also true for
> non-free and contrib. (At least when you want it to be built by the
> official builders.)

That doesn't appear to be the current situation on the buildds. The
official buildds, for packages in main, seem to include contrib but
not non-free binary packages in the chroot's apt sources.list files.
Both contrib and non-free source packages are available in the chroots
apt sources.list files. This appears to be the same for all three of
main, contrib, non-free. Take a look at any recent build log. Not sure
when it was changed, but ISTR it used to be that non-free but not
contrib were in the buildd chroots.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Philipp Kern
On 30.09.20 22:45, Josh Triplett wrote:
> [Accidentally sent this early before it was finished.]
> 
> Roland Fehrenbacher wrote:
>>> "S" == Sven Joachim  writes:
>> S> In addition, the packages in *main*
>> S> 
>> S> * must not require or recommend a package outside of *main* for
>> S>   compilation or execution (thus, the package must not declare a "Pre-
>> S>   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
>> S>   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
>> S>   unless that package is only listed as a non-default alternative for
>> S>   a package in *main*),
>>
>> Hmm, what I intend to do conforms to the first sentence of the paragraph
>> (the packages to go into main do not require or recommend a package
>> outside of *main* for compilation or execution),
> 
> The *source package* would, though, and that isn't allowed either.
> 
> One specific rationale for this: it must be possible for someone who
> *only* uses main to download the source, install the build dependencies,
> and successfully build the package themselves. Doing *that* must not
> require anything outside of main.

Somewhat ironically not depending on anything but main is also true for
non-free and contrib. (At least when you want it to be built by the
official builders.)

Kind regards
Philipp Kern



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Josh Triplett
Roland Fehrenbacher wrote:
> > "S" == Sven Joachim  writes:
> S> In addition, the packages in *main*
> S> 
> S> * must not require or recommend a package outside of *main* for
> S>   compilation or execution (thus, the package must not declare a "Pre-
> S>   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
> S>   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
> S>   unless that package is only listed as a non-default alternative for
> S>   a package in *main*),
> 
> Hmm, what I intend to do conforms to the first sentence of the paragraph
> (the packages to go into main do not require or recommend a package
> outside of *main* for compilation or execution),

The *source package* would, though, and that isn't allowed either.



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Josh Triplett
[Accidentally sent this early before it was finished.]

Roland Fehrenbacher wrote:
> > "S" == Sven Joachim  writes:
> S> In addition, the packages in *main*
> S> 
> S> * must not require or recommend a package outside of *main* for
> S>   compilation or execution (thus, the package must not declare a "Pre-
> S>   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
> S>   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
> S>   unless that package is only listed as a non-default alternative for
> S>   a package in *main*),
> 
> Hmm, what I intend to do conforms to the first sentence of the paragraph
> (the packages to go into main do not require or recommend a package
> outside of *main* for compilation or execution),

The *source package* would, though, and that isn't allowed either.

One specific rationale for this: it must be possible for someone who
*only* uses main to download the source, install the build dependencies,
and successfully build the package themselves. Doing *that* must not
require anything outside of main.



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Russ Allbery
Roland Fehrenbacher  writes:
>> "S" == Sven Joachim  writes:

> S> No, see Policy §2.2.1:

> S> In addition, the packages in *main*
> S> 
> S> * must not require or recommend a package outside of *main* for
> S>   compilation or execution (thus, the package must not declare a "Pre-
> S>   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
> S>   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
> S>   unless that package is only listed as a non-default alternative for
> S>   a package in *main*),

> Hmm, what I intend to do conforms to the first sentence of the paragraph
> (the packages to go into main do not require or recommend a package
> outside of *main* for compilation or execution),

If you need a non-free package to build the binary packages, that's what
"require a package for compilation" means.  That's referring to the build
of the binary packages.

Packages can only go into main if they can be built using only other
packages from main.

-- 
Russ Allbery (r...@debian.org)  



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Jonas Smedegaard
Quoting Roland Fehrenbacher (2020-09-30 20:47:58)
> > "S" == Sven Joachim  writes:
> 
> Hi Sven and Adam,
> 
> many thanks for your quick answers.
> 
> S> On 2020-09-30 19:31 +0200, Roland Fehrenbacher wrote:
> >> Hi,
> >> 
> >> a quick question to the list, since I didn't find an answer after
> >> a significant time of searching:
> >> 
> >> Is it allowed to have a source package with a build dependency on
> >> a pkg in non-free (in this particular case nvidia-cuda-toolkit)
> >> and resulting binary packages to go partly to main and others to
> >> contrib?
> 
> S> No, see Policy §2.2.1:
> 
> S> In addition, the packages in *main*
> S> 
> S> * must not require or recommend a package outside of *main* for
> S>   compilation or execution (thus, the package must not declare a "Pre-
> S>   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
> S>   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
> S>   unless that package is only listed as a non-default alternative for
> S>   a package in *main*),
> 
> Hmm, what I intend to do conforms to the first sentence of the 
> paragraph (the packages to go into main do not require or recommend a 
> package outside of *main* for compilation or execution), but not the 
> add-on in brackets.

How does first sentence conform to what you want to do?

Beware that a non-free source package is "outside of main".


> Is the only solution here then really to have two source packages with 
> exactly the same upstream source and only a difference in the way the 
> binaries are built and what they depend upon? In the end it would be a 
> rather large duplication of work, hence a rather big nuisance and 
> time-killer.

Depending on source structure, an alternative approach might be to build 
a binary -source package containing only the parts needed for linking 
with non-free code.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

signature.asc
Description: signature


Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Samuel Thibault
Roland Fehrenbacher, le mer. 30 sept. 2020 20:47:58 +0200, a ecrit:
>Is the only solution here then really to have two source packages
> with exactly the same upstream source and only a difference in
> the way the binaries are built and what they depend upon?

That's what I do with starpu and hwloc. In starpu the packaging
difference is really minimal so I use some sed scripts to switch between
the "main" version and the "contrib" version. In hwloc the difference
is more involved so I use two branches, and just pull from master to
contrib. In the end it's not really much additional work.

Samuel



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Roland Fehrenbacher
> "S" == Sven Joachim  writes:

Hi Sven and Adam,

many thanks for your quick answers.

S> On 2020-09-30 19:31 +0200, Roland Fehrenbacher wrote:
>> Hi,
>> 
>> a quick question to the list, since I didn't find an answer after
>> a significant time of searching:
>> 
>> Is it allowed to have a source package with a build dependency on
>> a pkg in non-free (in this particular case nvidia-cuda-toolkit)
>> and resulting binary packages to go partly to main and others to
>> contrib?

S> No, see Policy §2.2.1:

S> In addition, the packages in *main*
S> 
S> * must not require or recommend a package outside of *main* for
S>   compilation or execution (thus, the package must not declare a "Pre-
S>   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
S>   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
S>   unless that package is only listed as a non-default alternative for
S>   a package in *main*),

Hmm, what I intend to do conforms to the first sentence of the paragraph
(the packages to go into main do not require or recommend a package
outside of *main* for compilation or execution), but not the add-on in
brackets. Is the only solution here then really to have two source packages
with exactly the same upstream source and only a difference in
the way the binaries are built and what they depend upon?
In the end it would be a rather large duplication of work, hence a
rather big nuisance and time-killer.

I'm thankful for opinions/alternatives.

Roland


Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Adam D. Barratt
On Wed, 2020-09-30 at 19:31 +0200, Roland Fehrenbacher wrote:
> a quick question to the list, since I didn't find an answer after a
> significant time of searching:
> 
> Is it allowed to have a source package with a build dependency on a
> pkg in non-free (in this particular case nvidia-cuda-toolkit) and
> resulting binary packages to go partly to main and others to contrib?

Policy seems fairly clear here:

"
In addition, the packages in *main*

* must not require or recommend a package outside of *main* for
  compilation or execution (thus, the package must not declare a "Pre-
  Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
  Indep", or "Build-Depends-Arch" relationship on a non-*main* package
  unless that package is only listed as a non-default alternative for
  a package in *main*),
"

Regards,

Adam



Re: Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Sven Joachim
On 2020-09-30 19:31 +0200, Roland Fehrenbacher wrote:

> Hi,
>
> a quick question to the list, since I didn't find an answer after a
> significant time of searching:
>
> Is it allowed to have a source package with a build dependency on a pkg in
> non-free (in this particular case nvidia-cuda-toolkit) and resulting
> binary packages to go partly to main and others to contrib?

No, see Policy §2.2.1:

,
| In addition, the packages in *main*
| 
| * must not require or recommend a package outside of *main* for
|   compilation or execution (thus, the package must not declare a "Pre-
|   Depends", "Depends", "Recommends", "Build-Depends", "Build-Depends-
|   Indep", or "Build-Depends-Arch" relationship on a non-*main* package
|   unless that package is only listed as a non-default alternative for
|   a package in *main*),
`

Cheers,
   Sven



Allowed to build-depend a pkg in main on a pkg in non-free?

2020-09-30 Thread Roland Fehrenbacher
Hi,

a quick question to the list, since I didn't find an answer after a
significant time of searching:

Is it allowed to have a source package with a build dependency on a pkg in
non-free (in this particular case nvidia-cuda-toolkit) and resulting
binary packages to go partly to main and others to contrib? Current case
of doubt is the relion source package for which I would like to build
non-cuda (should go to main, no dependencies out of main) and
cuda-enabled (would go to contrib) binary package versions.

See https://salsa.debian.org/med-team/relion

Thanks,

Roland