bug#65391: Acknowledgement (People need to report failing builds even though we have ci.guix.gnu.org for that)

[Simon Tournier]

Hi Arne,

On Tue, 12 Sep 2023 at 01:12, "Dr. Arne Babenhauserheide" <arne_bab@web.de> 
wrote:

> I’m skipping a lot to get only to the most important points (save time
> for us all).

Good initiative, let me do the same. :-)


> That’s why I wrote the following:
>
>> If we had a way to have placeholder packages (similar to the renamings)
>> that emit warnings for missing packages but do not break the build, that
>> would reduce the damage done by removing a package. But I think such a
>> mechanism must be in place and tested before adding a rule to remove
>> packages.
>
> This would cause us to collect a slowly growing list of removed packages
> that will be ignored (except for the warning) in manifests.
>
> That way we would avoid breaking the setup when removing a package.
>
> (define-public-removed the-package-variable
>   (removed-package
>     (name "the-package-name")
>     (reason-for-removal "upstream stopped working a decade ago")))
>

Here you are defining a policy:

 1. set a rule for replacing the package by ’removed-package’
 2. set a rule for effectively removing this package

Somehow you are discussing to have a rule to deal with the broken
packages.   A policy, no? :-)

        Having a rule to deal with the regular broken packages appears to me a
        good thing and very helpful to keep Guix reliable.

Therefore, we agree that making a policy for dealing with broken
packages is worth and it would help to have a better Guix.

It appears to me better to know what I can expect as an user than to
have some surprise after each “guix pull”.  I have in mind the sudden
removal of Python 2 packages for instance.  With such policy, it would
have been smoother, IMHO.

That’s said, two minor points that does not matter much. :-)

I do not understand your explanations with the manifest because I do not
see the difference if one element of your manifest is broken or if this
very same element is removed.  For the both cases, your manifest is
broken, no?  From the point of view of the profile generation, broken or
removed does not change the result, isn’t it?  Broken or removed only
changes the process for investigating and try to fix, no?

The only case where it could matter is if your manifest relies on
package variant.  That case, if the package becomes broken, the variant
could not be.  Well, if that’s the case, I would suggest that you
maintain these packages using a plain copy of the inherited package.
Because a perfectly working update could break your variant.  I mean, if
your manifest relies on package variant, then this manifest is highly
dependant on the changes whatever the status of the package.

In all cases, I share your concerns, and as you, I am time to time
bitten by stuff that break.  If I am honest, I barely update my base
system.  Before an update, I carefully check a commit using “guix
time-machine” and test that my config works.  Somehow I often use the
command-line “guix time-machine -- shell -m”.

On a side note, I am not convinced we will have the resource to change
the package definition as your proposing.  That’s another story and it
appears to me the part of the discussion for a policy (strategy) for
removing packages.  I guess. :-)

That’s long enough. ;-)

Cheers,
simon