Hi,
the omission was not intentional, just a result of travel, family and gaveling
to remember too many things at once.
I’ll try to do a new upload when the kids fall asleep. I agree that fixing
buster is the only priority, I can handle the rest. It should be fairly easy as
there’s no new upstream release for 7.0, so I’ll just follow different
numbering schemes for external (7.0.33-<1,inf)) vs stretch
(7.0.33-0+deb7u<1,inf), so the conflict will be (<< 7.0.33-1~ and it should
just work fine.
Ondrej
--
Ondřej Surý <ond...@sury.org>
> On 13 Apr 2019, at 15:00, Ivo De Decker <iv...@debian.org> wrote:
>
> Hi,
>
>> On Wed, Apr 03, 2019 at 09:15:28PM +0200, Andreas Beckmann wrote:
>>> On 2019-04-03 13:45, Ondřej Surý wrote:
>>> Hi Andreas,
>>>
>>> there will be new upstream release of PHP 7.3 this week, so I’ll handle it
>>> as one batch, ok?
>
> I see you uploaded this new version to unstable without a fix for this bug.
>
>>> I just wonder if there’s a way how to fix that without breaking
>>> co-installability with php7.0-curl from external repositories.
>>
>> How does such a package look like? What dependencies does it have?
>> What's the versioning scheme?
>
> Do you have a pointer to those external repositories?
>
> If we can find a nice solution, that would be ok, but if not, I think fixing
> this issue in buster is more important than supporting external repositories.
>
>> We could try a Breaks: libcurl3 in php7.3-common.
>> ... trying ...
>> Nope, that only make it worse.
>>
>> Is stretch getting new php 7.0 point releases? In that case we can't
>> have a versioned
>> Breaks: php7.0-curl (<< external-repo-version-newer-than-stretch)
>> that will continue to be valid. (Unless the external repo versions come
>> with an epoch)
>>
>>> What if we fixed this in php7.0-curl package? (I keep separate sources for
>>> it.)
>>
>> I don't think there is much fixable in php7.0-curl, its the
>> libcurl{3->4} transition biting us here ...
>>
>> The big hammer that should work is
>> gcc-8-base: Breaks: libcurl3
>> but it's a completely unrelated package ...
>
> That doesn't seem like a realistic solution.
>
> Cheers,
>
> Ivo
>
