Re: Bug#753444: Bug#753542: perl-base - Segfaults in libperl.so.5.18
Control: reassign -1 perl-base,release.debian.org
Control: user release.debian.org@packages.debian.org
Control: usertags -1 transition
On 05/07/14 18:31, Niko Tyni wrote:
> On Sat, Jul 05, 2014 at 11:45:16AM +0200, Emilio Pozuelo Monfort wrote:
>> On 05/07/14 08:48, Niko Tyni wrote:
>
>> I have thought a bit more about this. I was hesitant as there are lots of
>> packages involved, but thinking more about it, this should be pretty smooth. You
>> add perlapi-5.18.2d to perl-base's Provides, but you won't remove perlapi-5.18.1
>> or perlapi-5.18.2. Then perl-base can migrate immediately, and all the rebuilds
>> can migrate as well. Then after the rebuilds are done, you can remove
>> perlapi-5.18.1 and perlapi-5.18.2 from Provides.
>
> I'm not very enthusiastic about this. It's basically lying: we don't offer
> the old ABI anymore so we should be straight about it. An uninstallable
> package seems better than a broken one.
>
> But I can see it would help the transition, and it wouldn't cause a
> regression, it would just make the fix take longer.
It would make the fix only take longer for people who do partial uploads, right?
The users who do a dist-upgrade and get all the updated perl modules that we
have binNMUed should be fine, right? And then after things have been rebuilt and
any potential FTBFS have been fixed, we drop the old perlapi Provides, and then
partial upgrades won't be possible (thus fixing that case as well). The
alternative is delaying the migration until everything has been rebuilt and all
the FTBFS bugs have been fixed. I think keeping the provides for now is a better
option, but I don't know Perl so I may be missing something. If you want to drop
them now, that's fine with me.
> So yes, I can do that if you want.
>
>>> What do we do with packages that fail to build? Remove the old s390x
>>> binaries from testing? The source packages are going to cause trouble
>>> for the 5.20 transition too, of course...
>>
>> For leaf packages, we could possibly remove them. But why not just fix them
>> wherever possible? Do you expect many FTBFS?
>
> Sure, fixing them is certainly preferrable :) It's just that I've
> recently rebuilt the same set of packages for the 5.20 transition and
> ISTR encountering quite a few known long-standing FTBFS bugs. I suppose
> those packages aren't in testing anymore, though; I didn't look at that
> part much in my tests.
I suppose you don't have a list?
#735623 could be a problem. #742409 as well. That's not an exhaustive list and I
haven't checked if those could be removed from testing (if they are leaf
packages). That's why I think a smooth transition (i.e. keeping the provides for
now) would be preferable.
That said, feel free to upload perl now.
Regards,
Emilio
Reply to: