| 1 |
On 08/17/2017 12:48 AM, Michał Górny wrote: |
| 2 |
> W dniu śro, 16.08.2017 o godzinie 22∶07 -0700, użytkownik Daniel |
| 3 |
> Campbell napisał: |
| 4 |
>> On 08/10/2017 01:10 AM, Michał Górny wrote: |
| 5 |
>>> On czw, 2017-08-10 at 09:54 +0200, Fabian Groffen wrote: |
| 6 |
>>>> On 10-08-2017 09:40:30 +0200, Michał Górny wrote: |
| 7 |
>>>>> On czw, 2017-08-10 at 06:58 +0200, Nicolas Bock wrote: |
| 8 |
>>>>>> On Mon, Jul 31, 2017 at 09:11:19AM +0200, Nicolas Bock wrote: |
| 9 |
>>>>>>> Hi, |
| 10 |
>>>>>>> |
| 11 |
>>>>>>> I would like to add neomutt to the tree. This new package is meant as |
| 12 |
>>>>>>> an alternative and not a replacement of the existing mutt package. |
| 13 |
>>>>>> |
| 14 |
>>>>>> Thanks for all of the great suggestions and feedback! |
| 15 |
>>>>>> |
| 16 |
>>>>>> This is round two. I have update the ebuild with all your |
| 17 |
>>>>>> suggestions. I have also added support for eselecting between mutt |
| 18 |
>>>>>> and neomutt. Before the eselect ebuild can land though, we need to |
| 19 |
>>>>>> rename the mutt binary so that the managed link can be called |
| 20 |
>>>>>> mutt. |
| 21 |
>>>>> |
| 22 |
>>>>> What for? How many people are exactly in the dire need of having both |
| 23 |
>>>>> installed simultaneously and switching between them? If you really can't |
| 24 |
>>>>> learn to type the new command, add IUSE=symlink blocking original mutt |
| 25 |
>>>>> and be done with it. Don't add more unowned files to /usr by another |
| 26 |
>>>>> poorly written eselect module. |
| 27 |
>>>> |
| 28 |
>>>> Be nice! No need to be bitchy here (and in the rest of your review). |
| 29 |
>>>> Nicolas is just trying. |
| 30 |
>>>> |
| 31 |
>>>> Me, as maintainer of Mutt, thought it was a good idea, because it allows |
| 32 |
>>>> people to easily have both installed at the same time, which in this |
| 33 |
>>>> interesting time for both projects is not a weird thing to have. |
| 34 |
>>> |
| 35 |
>>> I don't see how eselect helps that. People can just run neomutt by |
| 36 |
>>> typing... neomutt, right? It works without the symlink, right? |
| 37 |
>>> |
| 38 |
>>>> If there is a policy/move to get rid of eselect, then sorry, I am not |
| 39 |
>>>> aware of that. I can live with a symlink USE-flag. It doesn't seem |
| 40 |
>>>> very elegant to me, but it would work for this scenario. |
| 41 |
>>>> |
| 42 |
>>> |
| 43 |
>>> The move is against orphaned files in /usr that are randomly changed by |
| 44 |
>>> runtime tools rather than the package manager. |
| 45 |
>>> |
| 46 |
>> |
| 47 |
>> Then how do we explain the reasoning for the other 50 or so eselect |
| 48 |
>> modules? No doubt at least a handful of them modify symlinks in /usr, |
| 49 |
>> and have similarly few options to choose from, such as eselect-vi. |
| 50 |
>> Should we remove those as well? |
| 51 |
>> |
| 52 |
> |
| 53 |
> Mistakes of the past are no excuse to commit more mistakes. You should |
| 54 |
> know that because I had to repeat this many times. Some of the eselect |
| 55 |
> modules have been fixed since then giving major improvements (see: |
| 56 |
> eselect-opengl). |
| 57 |
> |
| 58 |
|
| 59 |
I can agree with that, but you seemed opposed to the entire idea of an |
| 60 |
eselect module for upstreams that own the same file; e.g. neomutt being |
| 61 |
a drop-in replacement for mutt. Are you instead opposing a |
| 62 |
cobbled-together eselect module? What would it take to ensure the RO |
| 63 |
/usr use-case could be supported while simultaneously allowing easy |
| 64 |
switching? Does eselect-opengl support RO /usr? If not, then it's a |
| 65 |
little unreasonable to expect other modules to do it since you pointed |
| 66 |
to it as a good example. |
| 67 |
|
| 68 |
What is your true opinion? |
| 69 |
-- |
| 70 |
Daniel Campbell - Gentoo Developer |
| 71 |
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net |
| 72 |
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6 |
Archives