On 08/17/2017 12:48 AM, Michał Górny wrote:
> W dniu śro, 16.08.2017 o godzinie 22∶07 -0700, użytkownik Daniel
> Campbell napisał:
>> On 08/10/2017 01:10 AM, Michał Górny wrote:
>>> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote:
>>>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote:
>>>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote:
>>>>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I would like to add neomutt to the tree. This new package is meant as 
>>>>>>> an alternative and not a replacement of the existing mutt package.
>>>>>>
>>>>>> Thanks for all of the great suggestions and feedback!
>>>>>>
>>>>>> This is round two. I have update the ebuild with all your 
>>>>>> suggestions. I have also added support for eselecting between mutt 
>>>>>> and neomutt. Before the eselect ebuild can land though, we need to 
>>>>>> rename the mutt binary so that the managed link can be called 
>>>>>> mutt.
>>>>>
>>>>> What for? How many people are exactly in the dire need of having both
>>>>> installed simultaneously and switching between them? If you really can't
>>>>> learn to type the new command, add IUSE=symlink blocking original mutt
>>>>> and be done with it. Don't add more unowned files to /usr by another
>>>>> poorly written eselect module.
>>>>
>>>> Be nice!  No need to be bitchy here (and in the rest of your review).
>>>> Nicolas is just trying.
>>>>
>>>> Me, as maintainer of Mutt, thought it was a good idea, because it allows
>>>> people to easily have both installed at the same time, which in this
>>>> interesting time for both projects is not a weird thing to have.
>>>
>>> I don't see how eselect helps that. People can just run neomutt by
>>> typing... neomutt, right? It works without the symlink, right?
>>>
>>>> If there is a policy/move to get rid of eselect, then sorry, I am not
>>>> aware of that.  I can live with a symlink USE-flag.  It doesn't seem
>>>> very elegant to me, but it would work for this scenario.
>>>>
>>>
>>> The move is against orphaned files in /usr that are randomly changed by
>>> runtime tools rather than the package manager.
>>>
>>
>> Then how do we explain the reasoning for the other 50 or so eselect
>> modules? No doubt at least a handful of them modify symlinks in /usr,
>> and have similarly few options to choose from, such as eselect-vi.
>> Should we remove those as well?
>>
> 
> Mistakes of the past are no excuse to commit more mistakes. You should
> know that because I had to repeat this many times. Some of the eselect
> modules have been fixed since then giving major improvements (see:
> eselect-opengl).
> 

I can agree with that, but you seemed opposed to the entire idea of an
eselect module for upstreams that own the same file; e.g. neomutt being
a drop-in replacement for mutt. Are you instead opposing a
cobbled-together eselect module? What would it take to ensure the RO
/usr use-case could be supported while simultaneously allowing easy
switching? Does eselect-opengl support RO /usr? If not, then it's a
little unreasonable to expect other modules to do it since you pointed
to it as a good example.

What is your true opinion?
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6