Re: [gentoo-dev] New package neomutt

[Nicolas Bock]

On Thu, Aug 10, 2017 at 10:10:04AM +0200, 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?

It does of course. What's appropriate here depends on whether we 
think somebody might want to have both mutt and neomutt installed 
at the same time. If we don't allow this use case, we don't have 
to worry about eselect and the neomutt binary will be called 
'mutt' (as it is called by upstream already). If we do allow this 
use case, being able to eselect makes sense because then the 
binary is still always called 'mutt'.

>> 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.

I don't quite understand the problem. Doesn't the package manager 
take care of symlinks installed by the eselect package?

>--
>Best regards,
>Michał Górny



-- 
Nicolas Bock <nicolasbock@g.o>