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 40FD81396D0 for ; Thu, 10 Aug 2017 09:35:57 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 538E71FC062; Thu, 10 Aug 2017 09:35:51 +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 E72B1E0D33 for ; Thu, 10 Aug 2017 09:35:50 +0000 (UTC) Received: from rubberducky.suse.de (p54BC8185.dip0.t-ipconnect.de [84.188.129.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nicolasbock) by smtp.gentoo.org (Postfix) with ESMTPSA id 367A334197A for ; Thu, 10 Aug 2017 09:35:49 +0000 (UTC) Date: Thu, 10 Aug 2017 11:35:45 +0200 From: Nicolas Bock To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] New package neomutt Message-ID: <20170810093545.qhgn7iuuxn6l5dfk@rubberducky.suse.de> 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> 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-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="s6ifdxowqilgbawf" Content-Disposition: inline In-Reply-To: <1502352604.1554.4.camel@gentoo.org> User-Agent: NeoMutt/20170714 (1.8.3) X-Archives-Salt: e9485ce0-0c39-406d-824d-3ff18783c23d X-Archives-Hash: 882c73b1943e62fcf970691e51be0682 --s6ifdxowqilgbawf Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 10, 2017 at 10:10:04AM +0200, Micha=C5=82 G=C3=B3rny wrote: >On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: >> On 10-08-2017 09:40:30 +0200, Micha=C5=82 G=C3=B3rny 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=3Dsymlink blocking original mu= tt >> > 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=20 think somebody might want to have both mutt and neomutt installed=20 at the same time. If we don't allow this use case, we don't have=20 to worry about eselect and the neomutt binary will be called=20 'mutt' (as it is called by upstream already). If we do allow this=20 use case, being able to eselect makes sense because then the=20 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=20 take care of symlinks installed by the eselect package? >--=20 >Best regards, >Micha=C5=82 G=C3=B3rny --=20 Nicolas Bock --s6ifdxowqilgbawf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQKTBAABCgB9FiEEU2lNM4ZQY0eES+u+HcDb5tcV6qcFAlmMKO9fFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDUz Njk0RDMzODY1MDYzNDc4NDRCRUJCRTFEQzBEQkU2RDcxNUVBQTcACgkQHcDb5tcV 6qcTOQ//Vk1RU7f3H3g+xRg79OMhjk4PWmYUpkpTVsu6M7UWNEJ4teZjPbZ6FW0n CLQ1guAK9byjk+h3ryBhJcjW9ymLYodRGebzq/7qpcuj0+rnSe00VAGsOOGJ2G5T 0s0N1PRiHB08+Je0Wrtc4vr0hL35zKiIlSGC6SE/RKuFZENKI9HOi0VdbShk0e9o kD8oT8Nn82X6Mnx1jniBZeUUTCY/qoFcPOwWk8+T38VsbkRkpxdrqriYy9v7/E5J EmfOULHNXGUoGrHffH+ANOsUW+SwHT3V0VhT88Jm5iFhuVgtF7/nzp5vRrI+vbOv 8tVy1RIxvgIPCzWMrran/y7EzPIAV1AVR03h1N2aYoigACvr+BuxIxnwYe1aNGJr wiNMUBjJE1ZlvA/WA5G0YmwS9WN+b+W4ykJYc9aPQqmRTz97uVnMp8Ix6jq1hDWi 0iyPj6rUeBJJsGgn6IiuaB6PQVmE423OPCoZlbb+91IZEx17u95Mask+ihS4ZlpG 8mRKLxJsW0dCItCorf4j97aNVv3+bqbkE0Kol5KSdcWwypKWvMqG03N40o+CF7qL QOhcAllvXKtlFfOODghA1t9DVzcnm/+oQrN09/bIxlxZ7U0IvhvXwqYjfJlEQ7dQ Mz06vrfD4aSPOMULHpOqHUEBjNKMd04iNIpuweOSPF4OOj3o17c= =WsQy -----END PGP SIGNATURE----- --s6ifdxowqilgbawf--