From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id E8E181396D0 for ; Thu, 17 Aug 2017 07:48:46 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 2526F1FC04A; Thu, 17 Aug 2017 07:48:40 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id CEE011FC00D for ; Thu, 17 Aug 2017 07:48:39 +0000 (UTC) Received: from pomiot (d202-252.icpnet.pl [109.173.202.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 5B2723416A5; Thu, 17 Aug 2017 07:48:38 +0000 (UTC) Message-ID: <1502956115.11219.1.camel@gentoo.org> Subject: Re: [gentoo-dev] New package neomutt From: =?UTF-8?Q?Micha=C5=82_G=C3=B3rny?= To: gentoo-dev@lists.gentoo.org Date: Thu, 17 Aug 2017 09:48:35 +0200 In-Reply-To: <2299f458-ff8d-172b-be45-a7a68c67a930@gentoo.org> References: <20170731071119.jccco5q4kd3fs4xs@rubberducky.suse.de> <20170810045857.e6qrvnimteopxgev@rubberducky.suse.de> <1502350830.1554.1.camel@gentoo.org> <20170810075443.GR1321@gentoo.org> <1502352604.1554.4.camel@gentoo.org> <2299f458-ff8d-172b-be45-a7a68c67a930@gentoo.org> Organization: Gentoo Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.24.5 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Archives-Salt: 3970db41-2593-471d-86ee-4f80155fc90c X-Archives-Hash: 6e8a08809491b22526efcd42e69bf990 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