Re: What to do when udpating a package ?

[Julien Lepiller]

Le 15 mai 2020 11:32:31 GMT-04:00, Edouard Klein <address@hidden> a écrit :
>Hi Julien,
>
>Thank you for your answer.
>
>Julien Lepiller writes:
>
>> Le 15 mai 2020 03:20:06 GMT-04:00, Edouard Klein
><address@hidden> a écrit :
>>>Dear Guix Developers,
>>>
>>>I have a few beginner questions.
>>>Attached to this email you will find the "reverse-package" graph of
>>>python-prompt-toolkit.
>>
>> Hi,
>>
>> In general, some packages on master may fail to build. We try to fix
>these, but it's not always easy.
>>
>> When updating a package, you should make sure that its dependents all
>> build or did not build before your changes. Fix those who now fail to
>> build.
>
>OK, got it. I'll avoid touching those that fail to build on the build
>farm.
>
>>
>> I don't think having both versions is a good thing because it will
>create conflicts when installing (have you tried to install a package
>that propagates both to a profile?). It would be ok if they had no file
>in common but I doubt it is the case. For any package that requires
>version 2, make sure its dependencies only use version 2, or update the
>package if the newer version can support version 3. It's not always
>easy to find the right order of upgrades, as you should make sure
>nothing is broken in between patches.
>>
>I did not try to install them, and you were correct, here is what I get
>when I try to install python-iml:
>
>guix install: error: profile contains conflicting entries for
>python-prompt-toolkit
>guix install: error:   first entry: python-prompt-toolkit@3.0.5
>/gnu/store/80lzvbzvfp4226ic7czhch4p0mlsdwlv-python-prompt-toolkit-3.0.5
>guix install: error:    ... propagated from python-ipython@7.9.0
>guix install: error:    ... propagated from python-iml@0.6.2
>guix install: error:   second entry: python-prompt-toolkit@2.0.7
>/gnu/store/0k7a0yp3b2sqqj8jhl7vp3cabb0x2mwd-python-prompt-toolkit-2.0.7
>guix install: error:    ... propagated from python-iml@0.6.2
>hint: You cannot have two different versions or variants of
>`python-iml' in the same profile.
>
>The problem is that python-iml depends on both python-ipython (which
>accepts python-prompt-toolkit 3) and python-prompt-toolkit-2. Looking
>at
>the github repo, the last update was in 2018, I don't think we'll see
>an
>update soon.
>
>I could pin python-ipython to python-prompt-toolkit-2, but that would
>just delay the problem and put it on somebody else's lap to let
>python-ipython move to python-prompt-toolkit 3.
>
>As I was typing a question I ctrl-Fed for 'variants' in the doc and
>ended up learning about package-input-rewriting. I will try to make
>python-iml depend on python-ipython, but with the prompt-toolkit input
>replaced with its version 2 on the fly. I think it makes sense. Is it
>the correct
>way to do what needs to be done ?

Sounds like a plan. Anotger possiblity is to introduce a patch to have 
python-iml support the latest version and send it upstream too.

>
>> Relying on propagated inputs to provide a dependency is going to
>> simplify the graphs, but not the work of other maintainers who will
>> have to investigate how the dependency is provided, so I don't think
>> it's a good idea.
>
>I understood your sentence as saying that relying on propagated inputs
>of propagated inputs is not a good idea and that dependencies are
>better
>explicitly stated in the guix package. Is that correct ?

Yes, that's what I meant. If the package explicitely requires something, we 
should provide it in the recipe, even if that's superfluous. If it's not listed 
as a dependency, then it's not necessary. I don't think this is an established 
rule, but this is what makes more sense to me.

>
>>
>> You should rebuild every dependent, even those who only depend on the
>> package for native-inputs, since there can be an error an any point
>> (though less likely).
>
>OK, I'll try that next when I'll have gotten python-iml to build.
>
>>
>> I hope I answered your questions. Your message was split into two
>> multipart sections and my client wasn't able to cite the interesting
>> part, which makes it hard for me to check what your questions were
>> while typing my answer.
>
>You have indeed answered a lot of them, thank you very much :) Sorry
>about the multipart stuff, I don't know how to configure my client
>(mu4e) not to do that. I'll look into it.

Don't worry too much about it, it's only inconvenient when I'm on my phone :)

>
>Cheers,
>
>Edouard.