Liliana Marie Prikler <liliana.prik...@gmail.com> writes: >> IIUC, the issue is that replacement packages are grafted post-build. >> This means that when emacs-dash is built, its AOT native-compilation >> happens with Emacs 29.3. However, at run-time Emacs 29.4 gets >> grafted in. > Nitpick: Emacs 29.4 gets grafted in at profile-building time.
Agreed; thanks for the correction. >> There are at least two possible ways (ignoring feasibility) to >> resolve this: >> >> 1. When emacs-dash etc. is being built we use Emacs 29.4 for native >> compilation. > That kinda defeats the point of grafting, though. At this point, > rebuilding with newer Emacs makes more sense. I agree, and that is what I am leaning towards. The main concern I have is that it's not directly apparent based on the package version whether the ABI_VERSION has been bumped or not. As such, any time a Guix packager proposes a replacement, the patch reviewer has to manually review the Emacs source to ensure that the ABI_VERSION has not been bumped. Unless there is an automated way to ensure that, this would increase the maintenance overhead in Guix (as compared to a comment noting that grafts for Emacs aren't recommended). However, perhaps there is a way to ensure that the proposed replacement doesn't have a different ABI_VERSION. Could this be caught by a test or "sanity checker" of some kind? >> 2. When emacs-dash etc. is being built we use Emacs 29.3 for native >> compilation, but ensure that said files are transferred to a >> location where Emacs 29.4 is able to find them. > Given that the ABI hash is used to guard against loading outdated > libraries like this, I'm not sure whether this makes too much sense. I > think what we would need is something like > > 3. Accurately capture the compatibility between Emacs-used-to-compile > and Emacs-used-to-run. I.e. find a way to enable Emacs cross > compilation. I see. Now your RFC patch regd. dropping the version prefix from the .eln path makes sense. The intent being to allow grafting to work with AOT native compilation as long as ABI_VERSION remains the same. > Perhaps upstream already has some ideas on this, perhaps not. Hopefully upstream also has some thoughts as to where assertions regd. the validity of package replacements could be tested. >> Which do we desire? My belief is that 1 is what we need, and that >> doing 2 may be inadequate for ensuring that appropriate security >> fixes are deployed (consider the case where the bug is in a macro in >> Emacs core). > I think 1 could be accomplished with a build system hack, but see > above. Noted, thank you for the elaboration. -- Suhail
