Re: [gentoo-dev] New package neomutt

[Michał Górny]

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

-- 
Best regards,
Michał Górny