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 <nicolasb...@gentoo.org>

Attachment: signature.asc
Description: PGP signature

Reply via email to