After install of Linutil get update error

[angryguy-win]

Describe the bug

A clear and concise description of what the bug is.

To Reproduce

Steps to reproduce the behavior:

1. clicked Linutil Installer
2. quit Linutil
3. run linutil
4. clicked update linutil
5. See error

Expected behavior

Used the Linutil to install its self pick the stable-bin
If i click on the Linutil update.
I get this error ??

Screenshots

Additional context

Add any other context about the problem here.

Checklist

• I checked for duplicate issues.
• I checked already existing discussions.
• This issue is not included in the roadmap.
• This issue is present on both stable and development branches.

[angryguy-win]

I even uninstalled it and tried again still the same

[koibtw]

Well, this is not an error (although technically it is).
I thought the message would be pretty self explanatory. You said:

Used the Linutil to install its self pick the stable-bin

I understand that by stable-bin you mean linutil-bin.
This is an AUR package. It clearly says This script only updates the binary installed through cargo..

/close not planned

[angryguy-win]

but that makes NO sense what so ever there an option to linutil installer and get replace by linuit update would you not assume this it suppose to update the installer ??..
there is no way this is working as intended ?... and if it is this is just dumb design ... the logic is flawed..
it give 3 option there nothing there about being install through cargo ..?,

[angryguy-win]

[angryguy-win]

[koibtw]

and if it is this is just dumb design ... the logic is flawed..
it give 3 option there nothing there about being install through cargo ..?
there is no way this is working as intended ?... and if it is this is just dumb design ... the logic is flawed..

This is working as intended and is not flawed. We're here to work on this project, not insult each others' work so please don't.
If you'd read the documentation (or have a basic understanding of our (and crate) packaging), you'd know that the crates.io package is only used as a fallback. It's not recommended to install standalone binaries through cargo, because updates just don't work.

Cargo is not a package manager.

That's why you don't see an option to install the crates.io package.

[angryguy-win]

It not an insult I'm trying to explain to you some thing ?... but your just not listening... if installer and update are not mutually exclusive then one should not replace the other this is confusing to user....
if they are two different thing then they should be two different things...

[koibtw]

I do understand your point and I know it may be confusing. Keeping both was my original idea but I reached out to the community for opinions and I think (don't really remember) that we decided to add a general preconditions if linutil exists in user's system. Theoretically, checking if the crate is installed and only then showing Linutil Updater would be a good idea but technically that would require changing a little too much in my opinion - adding an explicit cargo package check for linutil as a core functionality.
We could check for linutil in $HOME/.cargo/bin (file checking is already implemented) but although cargo is in $HOME/.cargo by default, it does not have to be the case for all users.

But yes I agree that we should probably change something here. Add a note about crates.io for example.

[angryguy-win]

Thank you that was it I wasn't trying insult you sorry if it seam that way, but a new user will never understand what that errors mean it will be very confusing to them... if they don't understand the difference they would assume there install in broken and that they cant update.. even for a some gracefuls handling that just does a yay -Syu linutil-bin or which method of choice, or at the least an error that newbies friendly like update this way this command ect ... or explain the crates.io

[koibtw]

No problem. I'll keep this issue in mind and do a bigger refactor of the scripts when I have time to do so. We want to focus more on fixing current bugs for now so UX gimmicks like this aren't our top priority ATM.
We might want to implement custom shell-command based preconditions for entries but a change like this, that could affect performance, will need a bigger discussion.
Anyway, thank you for reporting this, I will definitely be thinking of good solution. Other scripts might benefit from this aswell.