Why do you guys push drastic changes without fully considering the impact? about am

[ivan-hc]

OK gfolks, I'm going downgrade this, if you want to take a look to a snapshot of this, here you are a new branch

https://github.com/ivan-hc/AM/tree/experimental-6.6.3

[Samueru-sama]

Hi all! I just started experiencing the same "is not in the sudoers file. Permission denied." error upon update on Linux Mint.

What's the suggested way to fix that? P.S.: if possible, I'd prefer not having to uninstall am with all the am-managed AppImages in order to fix the issue.

Many thanks 🙏

sudo /opt/am/remove and wget https://raw.githubusercontent.com/ivan-hc/AM/main/INSTALL && chmod a+x ./INSTALL && sudo ./INSTALL

[nazdridoy]

@ivan-hc please marge #507

[nazdridoy]

and PLEASE @ivan-hc DO NOT PUSH MAJOR UPDATE WITHOUT TESTING FOR ATLEAST A WEEK OR ASKING OTHER CONTRIBUTORS FOR CODE REVIEW BEFORE MERGING!!

[ivan-hc]

@nazdridoy I can assure you that this is a feature that I have never seen the need for, to which I could easily apply patches without distorting all the permissions, as I have always done. You can't imagine how many times I was reluctant to accept change and instead got carried away by the constant requests. I am truly sorry and mortified by what happened. Sorry again.

As for the others, I was fine with version 6.6.2, and now, in the last 15 hours, we've turned around the computers of who knows how many other people. All around the world!

Thanks to everyone who pushed me to do this crazy shit. Thank you all. Really.

@Samueru-sama Thanks for cleaning up all the installation scripts, it's a change I'll keep.

For the rest, after everything we have said and done, the time wasted... I'm really, really pissed off right now! CAZZO!

[ivan-hc]

This change was because we had a pair of issues with people using AM on systems with many accounts.

You can re-install it to use it with the same privileges of other system admins, as I suggested in the message.

[ivan-hc]

Also see #496

[nazdridoy]

This change was because we had a pair of issues with people using AM on systems with many accounts.

You can re-install it to use it with the same privileges of other system admins, as I suggested in the message.

beta is important if you don't want to ruin user experience

[ivan-hc]

I've done the tests with @Samueru-sama

[nazdridoy]

I've done the tests with @Samueru-sama

not enough as you guys are probably using only debian based distro.

[ivan-hc]

@Samueru-sama uses Arch Linux and sometime "doas" instead of "sudo"

[nazdridoy]

at least consult with others or beta test before pushing major update

[nazdridoy]

@Samueru-sama uses Arch Linux and sometime "doas" instead of "sudo"
he is probably doesn't use wheel (default in arch)

[ivan-hc]

@nazdridoy you are right, but the issue here is that to solve the issues we are two of us on a widely used project. Its quite difficult to keep the rythm

[nazdridoy]

wheel is not used enough???

[ivan-hc]

wheel is not used enough???

I'm talking about AM

[nazdridoy]

thats why you NEED to be a bit slow to add new features.... we can't keep up with you.... its counterproductive..

[nazdridoy]

now i have to fix every instance of Sudu group add wheel....

[ivan-hc]

however, now AM does not work for me

[ivan-hc]

solved

[Samueru-sama]

why do you guys push breaking update without beta testing?

There was 💀

he is probably doesn't use wheel (default in arch)

I did notice that here and here

I also asked about the wheel group before here

But Ivan used the root group, I didn't think it was a big deal since the user could be added to the group by the installer. (I actually suggested to make an am group for this like other applications do that they make their own group).

My original idea was to make am and all the directories under /opt be owned by root and required sudo to modify those applications. Ivan didn't like that idea because it meant that you would need sudo to update the applications, to which I suggested a sudoers rule that would let the AM-updater run without password, but none of this got added in the end. 😅

thats why you NEED to be a bit slow to add new features

This wasn't a feature, it was a fix for #466 and #491

[nazdridoy]

why do you guys push breaking update without beta testing?

There was 💀

he is probably doesn't use wheel (default in arch)

I did notice that here and here

I also asked about the wheel group before here

But Ivan used the root group, I didn't think it was a big deal since the user could be added to the group by the installer. (I actually suggested to make an am group for this like other applications do that they make their own group).

My original idea was to make am and all the directories under /opt be owned by root and required sudo to modify those applications. Ivan didn't like that idea because it meant that you would need sudo to update the applications, to which I suggested a sudoers rule that would let the AM-updater run without password, but none of this got added in the end. 😅

thats why you NEED to be a bit slow to add new features

This wasn't a feature, it was a fix for #466 and #491

Seems like at least you have noticed and somewhat understand the issues that may be caused by these fixes. I'm wondering why you haven't stopped him from pushing it to the public before all things were ironed out?

This wasn't a feature, it was a fix for #466 and #491
a fix which causes new issues is not a fix. i do appreciate you trying to help fix these issues, but do believe changing permission of things especially root permission is something that everyone should be careful about.

I do like your idea to add a new group to manage these... Maybe create a PR, and we can review it. I will personally try to convince @ivan-hc if your implementation looks feasible and does not become a point of failure."

[ivan-hc]

honestly all this fiddling with permissions... it was something I didn't even want to do. I already liked AM like that, up until version 6.6.2

[ivan-hc]

@Samueru-sama I'm tempted to downgrade, again

this feature is causing too many problems that weren't there before

[Samueru-sama]

Seems like at least you have noticed and somewhat understand the issues that may be caused by these fixes. I'm wondering why you haven't stopped him from pushing it to the public before all things were ironed out?

Because after adding the user to the root group in INSTALL script everything worked on my end.

a fix which causes new issues is not a fix. i do appreciate you trying to help fix these issues, but do believe changing permission of things especially root permission is something that everyone should be careful about.

I do like your idea to add a new group to manage these... Maybe create a PR, and we can review it. I will personally try to convince @ivan-hc if your implementation looks feasible and does not become a point of failure."

Had it been done like I originally wanted, the only thing that would have changed is that AM would have asked for the sudo password to update. And to fix that you would just need to add a single sudoers rule, which AM could do that as well.

I still think that having directories in /opt be owned by the user is not ideal. And if I am not mistaken, these recent changes make /opt/am change ownership between the users that are updating it.

I'm tempted to downgrade, again

Go ahead.

[Samueru-sama]

@Samueru-sama Thanks for cleaning up all the installation scripts, it's a change I'll keep.

The $CACHEDIR changes can still be applied later on, it was the changes to permissions, groups and ownership that are the problem.

I specially made those '$CACHEDIR' changes because when am finally becomes owned by root (Which I think at this point you know that is the only solution for the multi user issues) the regular user could still launch am without needing sudo.

[ivan-hc]

@Samueru-sama Thanks for cleaning up all the installation scripts, it's a change I'll keep.

The $CACHEDIR changes can still be applied later on, it was the changes to permissions, groups and ownership that are the problem.

I specially made those '$CACHEDIR' changes because when am finally becomes owned by root (Which I think at this point you know that is the only solution for the multi user issues) the regular user could still launch am without needing sudo.

OK, you can do it. After that, I have to restyle tha APP-MANAGER to a form tha I can understand.

[ivan-hc]

@Samueru-sama actually... let me start first, I need to clean up some messes with functions and variables. Then I'll tag you when the time comes.

[horothesun]

Hi all! I just started experiencing the same "is not in the sudoers file. Permission denied." error upon update on Linux Mint.

What's the suggested way to fix that?
P.S.: if possible, I'd prefer not having to uninstall am with all the am-managed AppImages in order to fix the issue.

Many thanks 🙏