On czw, 2017-08-10 at 11:35 +0200, Nicolas Bock wrote: > 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'.
Considering that mutt has no revdeps, I doubt there's really any problem with 'just' calling it neomutt in Gentoo. In fact, it would be probably less confusing to the new users who do not expect it to be named '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? > It can't take care of /usr/bin/mutt symlink that will be edited by eselect. People with /usr read-only will have to establish yet another workaround to make this work. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
