Best course for recently fixed packages?

Best course for recently fixed packages?

[Jesse Gibbons]

There is a package I am defining that I want to push to the repository.
On github, its most recent release fails to build because it needs a
dependency that no longer exists. This was fixed in the master branch.
What should I specify as the commit?

Since I don't know when master will next be updated (it was last
updated 22 hours before when I decided to ask this and appears to be
updated almost daily) and each commit is likely to change the package's
sha256 hash, it does not make sense to specify that the commit is
"master". Should I instead specify master's current commit hash until
the project's next release? Or should I specify the most recent release
and specify a patch with the changes that fixed it? Or would it be best
for me to place this package on hold until the next release?

Thanks for the advice,
-Jesse

Re: Best course for recently fixed packages?

[Pierre Neidhardt]

[-- Attachment #1: Type: text/plain, Size: 308 bytes --]

In Guix you can never "follow upstream" in a package definition.  This
is because of the sha256 check that is done on the source, as a measure
for reproducibility.

The right course of action here is to specify the commit that builds.

Hope that helps!

-- 
Pierre Neidhardt
https://ambrevar.xyz/

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: Best course for recently fixed packages?

[Julien Lepiller]

Le 12 juin 2019 07:15:30 GMT+02:00, Jesse Gibbons <jgibbons2357@gmail.com> a écrit :
>There is a package I am defining that I want to push to the repository.
>On github, its most recent release fails to build because it needs a
>dependency that no longer exists. This was fixed in the master branch.
>What should I specify as the commit?
>
>Since I don't know when master will next be updated (it was last
>updated 22 hours before when I decided to ask this and appears to be
>updated almost daily) and each commit is likely to change the package's
>sha256 hash, it does not make sense to specify that the commit is
>"master". Should I instead specify master's current commit hash until
>the project's next release? Or should I specify the most recent release
>and specify a patch with the changes that fixed it? Or would it be best
>for me to place this package on hold until the next release?
>
>Thanks for the advice,
>-Jesse

It's usually better to use the latest release with a patch. If that's not possible, then you can indeed specify a commit hash that corresponds to master until the next release. Thanks!