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
