Re: Bug#930980: libcrypt-openssl-dsa-perl FTCBFS: configures and builds for the wrong architecture
Hi Niko,
On Thu, Jul 04, 2019 at 03:35:01PM +0300, Niko Tyni wrote:
> BTW I'd mostly forgotten about this but we've used liblocale-gettext-perl
> as a guinea pig in the archive for the current implementation, so you
> might want to have a look at it. Obviously the stuff in debian/rules
> should be moved to debhelper eventually.
I noticed it earlier, but didn't fully understand it. Meanwhile,
liblocale-gettext-perl is not cross-satisfiable due to its dependency on
perl-cross-config. I think you recently pointed out that it got messed
up. For the sake of experimentation, I replaced it with libperl5.28 and
doing so results in a cross buildable liblocale-gettext-perl. So yeah, I
confirm that this functionality should move to debhelper.
> I think something like this for Perl would mean major work upstream and
> is unlikely to happen.
I was not trying to suggest that perl should follow the Python 3.X
approach. I was merely pointing it out to have more context.
> Unfortunately, packages building Perl extensions ("XS modules") are not
> currently required to Build-Depend on anything else than "perl", which
> has sort of double role as it mainly means "the set of packages for a
> standard perl installation". It's currently M-A: allowed because of this
> double role and doesn't seem like a candidate for M-A:same (I think).
I'm left wondering why a standard perl installation would include 7MB
worth of C headers but no C compiler. Likely this has good reasons and
I'm not the first one to ask. If you happen to know a place to read up
on the rationale, please point me at it.
In the unlikely case of absence of reasons, I'm in favour of shrinking
the standard perl installation. Of course these headers would be needed
for building xs modules, so doing this would come at the cost of adding
a new Build-Depends to (you counted) 500 source packages.
> The only M-A:same package from src:perl is currently libperl5.28, though
> libperl-dev could also be made M-A:same if needed. (Despite the promising
> name, libperl-dev in its current form is not the entry point needed here:
> it's about building packages that embed a Perl interpreter and therefore
> link against libperl.so, not about building Perl extensions.)
I think M-A:same is not exactly what we need here. It's easier to say
that we need M-A:same, but what we need is the foreign Config.pm to be
coinstallable with the native perl. M-A:same is sufficient, but not
strictly necessary to get there.
> This looks like the way to go, though I think it would be better to
> just start it within pkg-perl packages first and amend the policy to a
> 'should' once there's a decent use base. Possibly 'perl-xs-build' would be
> a good name but I'm happy with whatever. I suppose it could be provided
> by libperl5.xx, so the dependency would be a no-op on native builds.
> (Unless there's a need for a separate real package that I don't see?)
Let us not confuse the final solution with the way to get there. When I
say that we should have some package that all xs-modules build depend
on, then that's the final solution. Obviously, we won't get there over
night. Starting with a few packages and scale up once we are confident
that it generally works. When to update policy is an interesting
question, but I think the final goal should be using a "must" here. If
all goes very well, we might be able to do that after buster+1 is
released.
> I'm not sure about the "generic concept" part as I see no benefits to this
> dependency outside cross building. Consequentially, I'm not quite sure
> how useful it is to add the dependency to all Perl extension packages
> regardless of whether they are otherwise cross buildable or not. But
> maybe there's worth in keeping those things separate and divide the big
> aim into smaller steps?
Yeah, this is part of the final goal vs. how to get there. Still, I
think that if 90% of perl extensions carry this new dependency, then
consistency is in favour of just adding it everywhere.
> I see ~500 source packages in the archive building XS modules (based on
> binary packages dependening on perlapi-5.x.x), with the pkg-perl group
> maintaining ~400 of them. So if all of them are to be touched, most of
> the work unsurprisingly falls on the pkg-perl group.
I'm in favour of starting way smaller: Making the debhelper part work
seems required to me. The next step seems to be updating
liblocale-gettext-perl. Once that works, we maybe try another 10
packages. After establishing confidence, mass-committing the 400
pgk-perl packages may be reasonable, but not any earlier.
> My feeling is that a decent coverage (maybe 50% or so?) could be achieved
> for bullseye "just" by updating the tooling and doing a mass commit
> early in the release phase, so packages would acquire the dependency
> when they are uploaded for other reasons.
I think agreeing on a schedule will not be a problem. In all of my cross
porting work, I've generally preferred the slow route that yields
maintainable solutions.
> Getting adoption to 100% for the pkg-perl packages would need a
> concentrated uploading effort of course.
Sounds like something we can discuss during the bookworm cycle.
Let me try to build consensus here from what we've learned thus far:
* We'll have to do "something" about perl-cross-config as it presently
does not "work".
* The things that liblocale-gettext-perl's debian/rules does should be
handled by debhelper.
* To facilitate cross building of xs modules, we'll have those xs
modules gain a new build dependency. This dependency has to ensure
that the host architecture Config.pm is available.
Then non-consensus:
* We need to decide the name of the new dependency. I vaguely proposed
perl-ext-build, but am now unconvinced of that. You refined it it to
perl-xs-build. I am now convinced that the -build suffix is not a
good idea as we usually call this -dev. What about perl-xs-dev?
* Having libperlX.YZ provide the new name is going to be problematic
during perl transitions as the package will be provided by multiple
libperlX.YZ, but only the one matching perl can be used. I guess we
need this to be a real package.
* Who is going to write the debhelper patch? I think I'd be able to do
it, but I presently lack the time to do it. Do you want to handle
this, Niko?
* Can we retire the virtual perl-cross-config package?
* We still disagree on whether all xs modules should carry the new
dependency or whether only those that are cross buildable should have
it.
Can you confirm or refine my consensus call and comment on the
non-consensus?
Helmut
Reply to: