Re: Bug#946655: dh_perl: why is ${perl:Depends} substituted as perl:any for programs only?
Hi Niko,
On Sun, Dec 15, 2019 at 11:12:35AM +0200, Niko Tyni wrote:
> FWIW your mail was initially somewhat confusing to me because of
> small terminology differences. I think you're using 'perl modules'
> for architecture independent, perl-only modules, and 'extensions' for
> architecture dependent plugins, usually compiled from C or C++. I'd
> call both of these 'perl modules', and my more specific names would
> be something like 'pure perl modules' and 'extension perl modules'
> (or 'XS perl modules').
I'm sorry for that. When I wrote "modules" I did mean "pure perl
modules" and when I wrote "extensions" I did mean "extension perl
modules". I'll try to remember that for future discussions.
> Of course there's no right or wrong here, just wanted to make sure we're
> talking about the same thing.
It's still best to not cause misunderstandings and we should use the
most common terminology here. In a similar way, I'm annoyed when people
use the mozilla host/target terminology instead of the gnu build/host
terminology.
> As for the actual question: your reasoning looks good to me as far as
> I could follow it, and I don't object to changing dh_perl so that it
> generates perl:any dependencies for pure perl module packages as well.
I fear that your other mail made me realize a mistake though. Unlike
python there is no standard installation. For perl it's perl-base and
perl. We cannot take perl for granted. Now perl pulls libperl5.30, which
contains extensions and we must preserve the architecture constraint
from our pure perl module to the relevant extension modules used from
libperl5.30.
For this reason, I now think that simply using perl:any for pure perl
modules may be wrong. However that depends on what we decide on Niko's
fork of the discussion as taken to the d-perl and d-cross lists.
To fix this, we could add libperl5.30 when annotating perl with :any for
pure perl modules. This is going to be bad for perl transitions however.
S libperl5.30 should likely provide the contained perl modules. It
doesn't do that today, because perl provides them instead, but we cannot
use the provides from perl, because they'd have to be provided from a
m-a:same package rather than a m-a:allowed package. So before we'd end
up going this route, we'd have to fundamenatlly change the perl
packaging.
I suggest that we continue discussing with Niko's fork and continue here
after reaching a conclusion there.
Helmut
Reply to: