amethyst
amethyst copied to clipboard
crystal-linux
[FEATURE]: Install PKGBUILD's from local paths
Is your feature request related to a problem? Please describe.
Like if you have a local copy of a PKGBUILD, you could use Amethyst to install them. Thinking about how to implement something like this, maybe we could uh copy the files to a cache folder or something?
Describe the solution you'd like
Something like ame ins --path . (like cargo install --path).
Describe alternatives you've considered
I don't really know any alternate solutions of how you could implement this into amethyst. I guess you could use makepkg -si.
Additional context
No response
I don't see why this should be implemented into amethyst when the user could just run makepkg
The advantage would be that ame is also able to handle aur dependencies while makepkg is not
The advantage would be that ame is also able to handle aur dependencies while makepkg is not
that's true, although how many would actually use that feature? it may not be worth the effort to implement and maintain it
im pretty sure some people might use it. ngl i prob would use it as resolving dependencies for local aur packages can be annoying af.
But why have locally cloned aur packages when you can just use amethyst to directly install it? amethyst is an aur helper, not a makepkg replacement
well there could be pkgbuilds that arent published to the aur or that are out of date on the aur
but it doesnt install aur deps. if your pkgbuild has aur deps, it will just tell you to install those manually.
is there any issues with manually installing dependencies? I still don't believe that many would actually use the feature since it's very rare to find a pkgbuild that's not in the aur
The thing is that this would be quite challenging to implement as we'd need to parse the PKGBUILD ourselves and I'm not sure if it would be worth the effort
it is hard to test how helpers would handle the pkgbuild
why would it be needed to test how helpers handle pkgbuilds? they all would be handled the same way as makepkg. If an aur helper doesn't, then it's a bug that should be reported
The thing is that this would be quite challenging to implement as we'd need to parse the PKGBUILD ourselves and I'm not sure if it would be worth the effort
What am I missing that prevents you from using the same approach as an AUR package? Aren't you still parsing the PKGBUILD to get dependencies normally?
And if you do the rewrite for this, then a git spec shouldn't be hard either.
The thing is that this would be quite challenging to implement as we'd need to parse the PKGBUILD ourselves and I'm not sure if it would be worth the effort
What am I missing that prevents you from using the same approach as an AUR package? Aren't you still parsing the PKGBUILD to get dependencies normally?
And if you do the rewrite for this, then a git spec shouldn't be hard either.
We parse dependencies through the AUR's RPC, rather than the PKGBUILD directly, which is generally what is recommended as attempting to parse any depends directly by source-ing the PKGBUILD could allow for arbitrary code execution in the case of a malicious PKGBUILD
The thing is that this would be quite challenging to implement as we'd need to parse the PKGBUILD ourselves and I'm not sure if it would be worth the effort
What am I missing that prevents you from using the same approach as an AUR package? Aren't you still parsing the PKGBUILD to get dependencies normally? And if you do the rewrite for this, then a git spec shouldn't be hard either.
We parse dependencies through the AUR's RPC, rather than the
PKGBUILDdirectly, which is generally what is recommended as attempting to parse anydependsdirectly bysource-ing thePKGBUILDcould allow for arbitrary code execution in the case of a maliciousPKGBUILD
Perhaps then you could have an unsafe confirm flag? If it's a local path or git repo it's more likely the user looked over it, after