Build phase to graft during build for better grafts QA

  • Done
  • quality assurance status badge
Details
2 participants
  • Léo Le Bouter
  • Ludovic Courtès
Owner
unassigned
Submitted by
Léo Le Bouter
Severity
normal
L
L
Léo Le Bouter wrote on 18 Mar 2021 12:38
(address . bug-guix@gnu.org)
618353059b4460b250ab12e0f556781e2ff07b56.camel@zaclys.net
Hello!

I am having an hard time testing grafts in GNU Guix while I think we
could have better tooling around this.

For example, we could have a package transformation that can add a
phase before 'check (or others) to graft any intermediate build binary
and all dependencies (if not done already) to run the test suite WITH
the graft. This could be turned on by GNU Guix contributors after
trying to graft some package to ensure it does not break things.

What do you think?

Léo
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBTO8QACgkQRaix6GvN
EKZ8nQ/+KqdxJf6ZgNju/wK9iA3isLxXwXWEzcaMRFZ3028FgIJdB0snwWn0hErq
NcBR4mx6YMKupuph7bHDCBDJo/BPbgk26u5FJAFtwCpi1cVCRlqWVWKie9Bew/zC
MSG73YHFLeG5Le9YHFvjiJtinwoLJpz5KJdLSuiTQUQNpTgiKV+pSs4T7iDRS48V
6erHnp/9F4zKeeFG3NHnYjBK1cXvBz+mSt4oPwvqdpxOyb8Y50kqXD3pgBN3EZHp
Xz/6k2yzshIU54tIyJuuAnV4KBIvCbfwLO8YaKw5BAWXQFnR87CA+kTFzlQBqeN8
v9bHdyTxcPztMc8RsRnV9d3cm7lAIIrF/oGWttWFiVO161vd7Jfko1Ojexql+0yL
+MV038fAklz+E3l4Om61cu280YLmNuAo0rD9Cit8Lkko5dPCfzmYTvt/keLIT1hc
VOTgPaQp3ljXHUCD1HEEgLWvmMEJ70ZP9GZZgAOzUR3JxIy80GE1cceGZ4b11G0M
OVyYLn5Mi/GXwb00kUWoBJGcKOtsnynqYg4JBMcibHKS2h47pbPawaDxz6AN7QvR
/naUtLeJ4lblMfitUXqdCle2cQTJKsKSaKBptrJtVkCXTEglhxi1MV+FBRlSZ4O+
fQB9Srowvh3He6RGmlZSW6/U1XyhVWN3XVUKh2agVgSU6PyakmY=
=8RC5
-----END PGP SIGNATURE-----


L
L
Ludovic Courtès wrote on 18 Mar 2021 21:41
(name . Léo Le Bouter)(address . lle-bout@zaclys.net)(address . 47230@debbugs.gnu.org)
87lfakkxdy.fsf@gnu.org
Hi,

Léo Le Bouter <lle-bout@zaclys.net> skribis:

Toggle quote (11 lines)
> I am having an hard time testing grafts in GNU Guix while I think we
> could have better tooling around this.
>
> For example, we could have a package transformation that can add a
> phase before 'check (or others) to graft any intermediate build binary
> and all dependencies (if not done already) to run the test suite WITH
> the graft. This could be turned on by GNU Guix contributors after
> trying to graft some package to ensure it does not break things.
>
> What do you think?

I think it’s more of a discussion for guix-devel than a bug report. :-)

What you describe, AIUI, is not possible: there are no phases or
anything like that happening on grafted packages. Quoth the manual
(info "(guix) Security Updates"):

Other restrictions may apply: for instance, when adding a graft to a
package providing a shared library, the original shared library and its
replacement must have the same ‘SONAME’ and be binary-compatible.

As I wrote earlier today, these things have to be checked by packagers;
they’re not easily automated because that usually involves knowing the
intent of upstream developers, for example whether they intend the new
version to be ABI-compatible with the version we have at hand, etc.

HTH!

Ludo’.
L
L
Ludovic Courtès wrote on 18 Mar 2021 21:41
control message for bug #47230
(address . control@debbugs.gnu.org)
87k0q4kxdl.fsf@gnu.org
tags 47230 notabug
close 47230
quit
L
L
Léo Le Bouter wrote on 19 Mar 2021 10:44
Re: bug#47230: Build phase to graft during build for better grafts QA
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 47230@debbugs.gnu.org)
33efef8bb2595bb93282ae429d96d60bce28b413.camel@zaclys.net
On Thu, 2021-03-18 at 21:41 +0100, Ludovic Courtès wrote:
Toggle quote (3 lines)
> I think it’s more of a discussion for guix-devel than a bug
> report. :-)

Yes but then I was thinking how do we track progress without losing it
in the pile of emails from guix-devel people receive everyday which
made me create a bug in the idea of "feature-request".. don't know.

Toggle quote (10 lines)
> What you describe, AIUI, is not possible: there are no phases or
> anything like that happening on grafted packages. Quoth the manual
> (info "(guix) Security Updates"):
>
> Other restrictions may apply: for instance, when adding a graft to
> a
> package providing a shared library, the original shared library and
> its
> replacement must have the same ‘SONAME’ and be binary-compatible.

I am not sure we understand each other, I am proposing we could add
tooling to aid that testing.

Toggle quote (10 lines)
> As I wrote earlier today, these things have to be checked by
> packagers;
> they’re not easily automated because that usually involves knowing
> the
> intent of upstream developers, for example whether they intend the
> new
> version to be ABI-compatible with the version we have at hand, etc.
>
> HTH!

Yes of course, but aided by tooling that process can me smoother, e.g.
figuring out the SONAME has changed could at least be checked
automatically and issue a warning/error. Same thing with abidiff etc.
these tools are really great and we could create an easy way to run the
test suite of a package with the graft in also.

Toggle quote (2 lines)
> Ludo’.

Thank you
-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEFIvLi9gL+xax3g6RRaix6GvNEKYFAmBUcosACgkQRaix6GvN
EKY+URAAmtfptKmccNr90DOyXF0R5FTU6sTz720Eoui2OzSmnS4pBhftDC3e3BRr
ka2UPIPhb2CG5Hy+V7Lsh6QWX1ac+ko9gQ0cNu2GzFzFqFTEhEYS3RUVxqy0gKGE
287zJmouJEL2l8p+pjtszNIgQWcZE18C7LrrJW6LJVV6hGppl/QMpaKaz111kiiz
iRfj5FvprDKozVLLlLdTO+g6jSXmw1qHvM6hYBXK85b6cl5iTjJIQRazbvgn2hA3
lHakRSyBbWiZObV9/HAvYRSnCLe6VtbAGlZcYCPU+5aFLVc9JWcYta6PNfYXK+jn
cA0iI5Au3YnFubXQY/rCy01AAEpkAJ0K5SJrYCp3k9v4bofTB1P89Ft0nm3jgENU
VNC9o1MxHWkEjCWhqx3M2YUE/q5XOKx8rsWsTdVg/vSh7gl0T7auOYugB3IaKXTw
7HwmkPaPUFIJSlXrHA/mNPXi1Pn0Fv38pPED2zyEwjZs+5Nnac+fWEYuiC3c4q1l
AbTeIGQwZIqV49UB9tnO5M22o8nhvLJ4VVG66yHY4A9t+w2QbAkdLB7tn+34p/Ds
mmNHdmIFqrfFY6El4tnO9V4tdLBf/9+Ed9q58sBLq1hISCS4Vaq96w7EzvKhXbgG
QqIquBMobFDJU+zwJmhh3GVru+VtUTa/mYYPvVT6RcsBiSDvjaQ=
=NiaE
-----END PGP SIGNATURE-----


?
Your comment

This issue is archived.

To comment on this conversation send an email to 47230@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 47230
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch