Arch Linux User Repository

@DuckSoft @yochananmarqos Any idea why this would need root anyways, besides of writing to /opt tree ?

i may want to split the WebUI outside ventoy-bin, then patch the source & build that webui as another package.

That sounds reasonable.

@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