bug#43893: [PATCH v3] maint: update-guix-package: Prevent accidentally breaking guix pull.

["Ludovic Courtès" <ludo@gnu.org>]

Hi Maxim,

Maxim Cournoyer <maxim.cournoyer@gmail.com> skribis:

> Ludovic Courtès <ludo@gnu.org> writes:
>
> [...]
>
>>> Currently, we have:
>>>
>>> time make update-guix-package
>>> git rev-parse HEAD
>>> 4893a1394e2eb8b97995b491f2f37ed85513a20f
>>> ./pre-inst-env "/gnu/store/i7z4pfa0c22q0qkxyl7fy2nlp3w658yg-profile/bin/guile"                  \
>>>    ./build-aux/update-guix-package.scm  \
>>>    "`git rev-parse HEAD`"
>>> error: Commit 4893a1394e2eb8b97995b491f2f37ed85513a20f is not pushed upstream.  Aborting.
>>> make: *** [Makefile:6507: update-guix-package] Error 1
>>
>> I agree that the better diagnostic is nice.  Though it’s a script that’s
>> essentially for a handful of people, who can certainly cope with the
>> ugly error.
>>
>> Anyway, I think we didn’t analyze the initial situation well enough
>> (myself included, by not commenting early and accurately).  I’m also not
>> fond of the added complexity and the risk of surprises when we make the
>> release, but OTOH, it’s no big deal in the big picture!
>
> I'm sorry but I don't agree with the "we didn't analyze the initial
> situation well enough";

The reason I wrote that is that we had overlooked the fact that
‘update-guix-package’ purposefully allows non-upstream commits, and
that’s what allows ‘make release’ to work.

It didn’t occur to me at the time, but the simplest path would have been
to conditionalize the bit that makes it possible to refer to
non-upstream commits.

> if I had to think about the best way to solve this problem now, I'd
> still choose the way that was chosen then, as it provides the best
> guarantee against producing a broken Guix package, something that
> happened a couple times in the past, judging from git log.  About
> complexity, I'd much rather the tool break on me than breaking 'guix
> pull' for everyone :-).

I agree that addressing this problem was in order.  :-)  The added
complexity brings its own set of (less serious) issues though.

>>>> BTW, in ‘make release’ does ‘make update-guix-package’ and expects it to
>>>> work with a not-pushed-yet commit.  So it’s a case where we need
>>>> GUIX_ALLOW_ME_TO_USE_PRIVATE_COMMIT=yes.
>
> I want to be able to run 'make release' first to test this works
> correctly, but even after rebuilding my source tree from scratch
> (following a 'make distclean'), and also attempting 'make download-po',
> and following release.org from guix-maintenance, I still get:
>
> make[3]: *** No rule to make target 'po/doc/guix-manual.pot', needed by 'distdir-am'.  Stop.

Oh my bad; the solution appears to be:

  make doc-pot-update

Lemme know how it goes!

Ludo’.