| Git Clone URL: | https://aur.archlinux.org/ventoy-bin.git (read-only, click to copy) |
|---|---|
| Package Base: | ventoy-bin |
| Description: | A new bootable USB solution |
| Upstream URL: | http://www.ventoy.net |
| Keywords: | boot image iso multiboot usb |
| Licenses: | GPL-3.0-or-later |
| Conflicts: | ventoy |
| Provides: | ventoy |
| Submitter: | DuckSoft |
| Maintainer: | DuckSoft (KokaKiwi, yochananmarqos, Kr1ss) |
| Last Packager: | yochananmarqos |
| Votes: | 329 |
| Popularity: | 13.44 |
| First Submitted: | 2020-05-19 06:14 (UTC) |
| Last Updated: | 2024-05-19 16:20 (UTC) |
@yochananmarqos inspected the code carefully... a quick and dirty fix is to put WebUI directory back then.
But there's something awful: it's executed as root, but he's putting crap log.txt directly in the binary directory, which is...
I'd try hard to fix the package, but if things are going worse, i may want to split the WebUI outside ventoy-bin, then patch the source & build that webui as another package.
Does the new Ventoy Web GUI work for anyone else?
https://www.ventoy.net/en/doc_linux_webui.html
sudo /opt/ventoy/VentoyWeb.sh
I just get a 404 error opening http://127.0.0.1:24680
Never mind, thx for your comment anyways !
You are completely correct, thanks for the detailed explanation.
I misunderstood how the two packages interacted, so sorry for the pointless request.
Ah. So, we could add exfatprogs as an optional dependency, but that won't automatically install it if neither of the two is present.
If we put it in depends though, exfat-utils will be uninstalled b/c exfatprogs conflicts with it :
$ LANG=C pacman -Si exfat{-utils,progs}
Repository : community
Name : exfat-utils
[...]
Provides : fuse-exfat
Optional Deps : None
Conflicts With : fuse-exfat
Replaces : fuse-exfat
[...]
Repository : community
Name : exfatprogs
[...]
Provides : exfat-utils
Depends On : glibc
Optional Deps : None
Conflicts With : exfat-utils
Replaces : None
[...]
Note Provides and Conflicts With in the output for exfatprogs.
However, since we depend on exfat-utils, the user is able to choose which of the two they want installed.
In my understanding if you rewrite the PKGBUILD to target exfatprogs, it'll just be preferred, but still the dependency still satisfied by exfat-utils, not breaking existing setups.
I didn't mean to ONLY hardcode depends on exfatprogs, just to depend on it by default.
I may be understanding it wrong.
I agree though that if this were to change, it'd be a good idea to wait til the next Linux LTS, since exfatprogs doesn't seem to have an explicit >=5.7 dependency thus would likely break in a weird way for LTS users.
I don't think so @C0rn3j :
If we depend on exfatprogs, on systems w/ installed exfat-utils the latter would have to be uninstalled in order to install ventoy-bin - although obviously the user previously decided to install it.
We shouldn't be making the decision in the users' place which dependency they install.
Just my two cents. Cheers !
(E/) spelling
PS Also, exfatprogs appears to need a >=5.7 kernel, which would mean it couldn't be used w/ e.g. current linux-lts-5.4.71.
Wouldn't it be better to directly depend on exfatprogs, instead of exfat-utils? Currently if one didn't previously have either, the older exfat-utils is preferred in this PKGBUILD.
As far as I understand, that's the official implementation from Samsung for the driver which was introduced in Linux 5.7.
https://www.phoronix.com/scan.php?page=news_item&px=Samsung-exFAT-Utils-Release
@Kr1ss: Nice catch, I somehow missed that when I looked. Namcap also detected lib32-glibc was missing.
Pinned Comments