Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> Ludovic Courtès <l...@gnu.org> wrote: >> Mark H Weaver <m...@netris.org> skribis: >> >>> (define-public emacs-next >>> (let ((commit "c36c5a3dedbb2e0349be1b6c3b7567ea7b594f1c") >>> (revision "0") >>> (emacs-version "27.0.91")) >>> (package >>> (inherit emacs) >>> (name "emacs-next") >>> (version (git-version emacs-version revision commit)) >>> (source >>> (origin >>> (inherit (package-source emacs)) >>> (method git-fetch) >>> (uri (git-reference >>> (url "https://git.savannah.gnu.org/git/emacs.git";) >>> (commit commit))) >> >> This can be handled with ‘--with-git-url’. > > I think that wouldn't work in this case, because we also need to > preserve the existing 'patches' and 'snippet' fields, which I arranged > to inherit above via (inherit (package-source emacs)). That probably > deserves a comment, since it's easily overlooked. > >>> (sha256 >>> (base32 "0mlrg2npy1r79laahkgzhxd1qassfcdz8qk1cpw7mqgf6y5x505h")) >>> (file-name (git-file-name name version)))) >>> (native-inputs >>> `(("autoconf" ,autoconf) ; needed when building from trunk >>> ,@(package-native-inputs emacs))) >> >> For this, we’d need a new ‘--with-extra-input’ package transformation >> option or similar. That way, we wouldn’t even need an ‘emacs-next’ >> package: people would just run >> >> guix install emacs --with-git-url=… --with-extra-input=autoconf > > There's also the 'native-search-paths' field, which cannot simply be > inherited because of the version number embedded within EMACSLOADPATH. > This particular issue could be avoided if the 'native-search-paths' > field were a function of the version number, but that raises migration > issues and I'm not sure it's worth it. > > What do you think? Ah yes, both good points that I had overlooked. Thanks, Ludo’.
