1 |
On czw, 2017-08-10 at 11:35 +0200, Nicolas Bock wrote: |
2 |
> On Thu, Aug 10, 2017 at 10:10:04AM +0200, Michał Górny wrote: |
3 |
> > On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: |
4 |
> > > On 10-08-2017 09:40:30 +0200, Michał Górny wrote: |
5 |
> > > > On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote: |
6 |
> > > > > On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote: |
7 |
> > > > > > Hi, |
8 |
> > > > > > |
9 |
> > > > > > I would like to add neomutt to the tree. This new package is meant as |
10 |
> > > > > > an alternative and not a replacement of the existing mutt package. |
11 |
> > > > > |
12 |
> > > > > Thanks for all of the great suggestions and feedback! |
13 |
> > > > > |
14 |
> > > > > This is round two. I have update the ebuild with all your |
15 |
> > > > > suggestions. I have also added support for eselecting between mutt |
16 |
> > > > > and neomutt. Before the eselect ebuild can land though, we need to |
17 |
> > > > > rename the mutt binary so that the managed link can be called |
18 |
> > > > > mutt. |
19 |
> > > > |
20 |
> > > > What for? How many people are exactly in the dire need of having both |
21 |
> > > > installed simultaneously and switching between them? If you really can't |
22 |
> > > > learn to type the new command, add IUSE=symlink blocking original mutt |
23 |
> > > > and be done with it. Don't add more unowned files to /usr by another |
24 |
> > > > poorly written eselect module. |
25 |
> > > |
26 |
> > > Be nice! No need to be bitchy here (and in the rest of your review). |
27 |
> > > Nicolas is just trying. |
28 |
> > > |
29 |
> > > Me, as maintainer of Mutt, thought it was a good idea, because it allows |
30 |
> > > people to easily have both installed at the same time, which in this |
31 |
> > > interesting time for both projects is not a weird thing to have. |
32 |
> > |
33 |
> > I don't see how eselect helps that. People can just run neomutt by |
34 |
> > typing... neomutt, right? It works without the symlink, right? |
35 |
> |
36 |
> It does of course. What's appropriate here depends on whether we |
37 |
> think somebody might want to have both mutt and neomutt installed |
38 |
> at the same time. If we don't allow this use case, we don't have |
39 |
> to worry about eselect and the neomutt binary will be called |
40 |
> 'mutt' (as it is called by upstream already). If we do allow this |
41 |
> use case, being able to eselect makes sense because then the |
42 |
> binary is still always called 'mutt'. |
43 |
|
44 |
Considering that mutt has no revdeps, I doubt there's really any problem |
45 |
with 'just' calling it neomutt in Gentoo. In fact, it would be probably |
46 |
less confusing to the new users who do not expect it to be named 'mutt'. |
47 |
|
48 |
> > > If there is a policy/move to get rid of eselect, then sorry, I am not |
49 |
> > > aware of that. I can live with a symlink USE-flag. It doesn't seem |
50 |
> > > very elegant to me, but it would work for this scenario. |
51 |
> > > |
52 |
> > |
53 |
> > The move is against orphaned files in /usr that are randomly changed by |
54 |
> > runtime tools rather than the package manager. |
55 |
> |
56 |
> I don't quite understand the problem. Doesn't the package manager |
57 |
> take care of symlinks installed by the eselect package? |
58 |
> |
59 |
|
60 |
It can't take care of /usr/bin/mutt symlink that will be edited by |
61 |
eselect. People with /usr read-only will have to establish yet another |
62 |
workaround to make this work. |
63 |
|
64 |
-- |
65 |
Best regards, |
66 |
Michał Górny |