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. -- Best regards, Michał Górny
Description: This is a digitally signed message part