[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Exploiting hashes for Scheme refactoring
From: |
Ludovic Courtès |
Subject: |
Re: Exploiting hashes for Scheme refactoring |
Date: |
Sat, 10 Jul 2021 16:27:21 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) |
Hi,
Nathan Benedetto Proença <nathan@vieiraproenca.com> skribis:
> Is it a good idea to exploit Guix hashing infrastructure to ensure that
> a Scheme refactoring did not change the packages produced?
> Has some developer already done that?
> Are there another tools and techniques I should be aware of?
>
> As I said in the other email I sent to the mailing list, I am interested
> in upgrading the texlive package in tex.scm.
> Depending on what you teach me there, a solution could involve changing
> more than 100+ places where the origin of packages is specified.
>
> Without proper tooling, this can demand a whole lot of developer time
> --- be it my time, or other contributors time.
> Would this imply more than 100+ patches submitted and reviewed, and
> perhaps in an alternative branch which core developers would have to
> maintain?
>
> Then I noticed I could use the hashes for the packages produced as a
> test of whether my refactor was satisfactory or not.
I’m not sure I fully understand the use case. If you’re changing the
way a package is produced, but you know that it should be a “silent
change” (i.e., not involving a rebuild of that package), you can check
that the derivation for the package remains unchanged by running:
./pre-inst-env guix build texlive --no-grafts -d
before and after the change.
If you’re changing origins, for example from one URL to another, the
.drv will be different but the package won’t need to be rebuilt.
HTH!
Ludo’.