Bug#912914: gap breaks multiple autopkgtests

[Jerome BENOIT]

Hello,

I have just have began to have a look on this issue.

It appears that gap-io does no more build with gap 4.10 :
a closer look reveals that /usr/lib/gap is missing some folder previously provided with the gap-dev package:

/usr/lib/gap/bin/x86_64-pc-linux-gnu-default64
/usr/lib/gap/gen
/usr/lib/gap/src

I have also noticed that

gac is no more on /us/bin but in  /usr/lib/gap 


Are this change expected ? or is it a bug ?


Cheers,
Jerome

On 20/12/2018 13:53, Jerome BENOIT wrote:
> 
> 
> On 20/12/2018 12:32, Paul Gevers wrote:
>> Hi Bill,
>>
>> On Sun, 4 Nov 2018 22:17:45 +0100 Bill Allombert <ballombe at debian.org>
>> wrote:
>>> On Sun, Nov 04, 2018 at 09:57:59PM +0100, Paul Gevers wrote:
>>>> With a recent upload of gap the autopkgtest of gap-float, gap-guava,
>>>> gap-io, gap-laguna, gap-openmath, gap-scscp and gap-sonata fail in
>>>> testing when their autopkgtests are run with the binary packages of gap
>>>> from unstable. It passes when run with only packages from testing. In
>>>> tabular form:
>>
>> Nearly the same is now happening with your upload of gap/4r10p0-3.
> 
> Indeed, I will have a look this week-end.
> 
> 
>>
>>> However, I am not the author of this autopkgtest and I do not maintain
>>> gap-float etc. and I have notified the maintainers in advance of the
>>> migration to GAP 4r9, so I expect them to deal with this issue, since it
>>> was expected.
>>
>> I assume you have informed your reverse dependencies again.
>>
>> Trying to be helpful... Apparently in the gap ecosystem, packages need
>> to migrate in lockstep. I am wondering, can't you change the packaging,
>> such that this is recognized as a (sort of) transition? If you can't
>> rename the "library" package in a similar way as libraries do in Debian,
>> you could provide a API virtual package that your reverse dependencies
>> depend on (potentially embedded during build, than the package has a
>> chance of only requiring a binNMU; I don't know the gap ecosystem if
>> that is feasible). Than at least the migration software knows to hold of
>> the migration until all packages are ready, even without those
>> autopkgtest failures.
>>
>> Paul
>>
>>
> 
> Cheers,
> Jerome
> 
> 

-- 
Jerome BENOIT | calculus+at-rezozer^dot*net
https://qa.debian.org/developer.php?login=calculus@rezozer.net
AE28 AE15 710D FF1D 87E5  A762 3F92 19A6 7F36 C68B

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1528 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/debian-science-maintainers/attachments/20181225/d9b85968/attachment.sig>