[Enhancement] Deprecate scriptdata/installers for Arch(based) distro

clsty commented 2 weeks ago

To let the system becomes cleaner (specifically the /usr/local/*), we'd better deprecate scriptdata/installers at least for Arch(based) distro, and instead use local PKGBUILDs to install them, so that they are managed by pacman.

Currently I've done the part for AGS.

I've found a problem that paru seems not supporting cleanbuild. Note that --clean is not cleanbuild, but "remove unneeded dependencies".

yay supports it by specifying --answerclean=a.

So, what about we not use paru but stick to yay instead? Else we'll need to find out how to cleanbuild when using paru. @end-4

end-4 commented 2 weeks ago

ugh sure, paru users can install yay just fine justt let them know

clsty commented 2 weeks ago

justt let them know

[./install.sh]: "yay" not found.
[./install.sh]: The definition of function "install-yay" is as follows:
install-yay 是函数
install-yay () 
{ 
    x sudo pacman -S --needed --noconfirm base-devel;
    x git clone https://aur.archlinux.org/yay-bin.git /tmp/buildyay;
    x cd /tmp/buildyay;
    x makepkg -o;
    x makepkg -se;
    x makepkg -i --noconfirm;
    x cd $base;
    rm -rf /tmp/buildyay
}
####################################################
[./install.sh]: Next command:
install-yay
Execute? 
  y = Yes
  e = Exit now
  s = Skip this command (NOT recommended - your setup might not work correctly)
  yesforall = Yes and don't ask again; NOT recommended unless you really sure
====>

When yay does not exist, the script will run like this. So, yeah they will know it.

moetayuko commented 2 weeks ago

I've found a problem that paru seems not supporting cleanbuild. Note that --clean is not cleanbuild, but "remove unneeded dependencies".

why is this needed? makepkg cleans $srcdir unless you pass the -e flag

clsty commented 2 weeks ago

I've found a problem that paru seems not supporting cleanbuild. Note that --clean is not cleanbuild, but "remove unneeded dependencies".

why is this needed? makepkg cleans $srcdir unless you pass the -e flag

According to Hyprland Wiki: If you are using the AUR (hyprland-git) package, you will need to cleanbuild to update the package. Paru has been problematic with updating before, use Yay.

If that "makepkg cleaning $srcdir" is sufficient as "cleanbuild", I think there should not be this note in Hyprland Wiki, right?

moetayuko commented 2 weeks ago

I've found a problem that paru seems not supporting cleanbuild. Note that --clean is not cleanbuild, but "remove unneeded dependencies".

why is this needed? makepkg cleans $srcdir unless you pass the -e flag

According to Hyprland Wiki: If you are using the AUR (hyprland-git) package, you will need to cleanbuild to update the package. Paru has been problematic with updating before, use Yay.

I've been using paru to update hyprland-git w/o issues for long. Dunno why cleanbuild is marked necessary here, but I guess it's somewhat related to git submodules.

If that "makepkg cleaning $srcdir" is sufficient as "cleanbuild", I think there should not be this note in Hyprland Wiki, right?

Yes, yay cleanbuild refers to cleaning the entire folder containing PKGBUILD. paru appears not to provide such a feature, but I suggest cleaning it manually rather than promoting users to use yay which is overkill from my point of view:

XDG_CACHE_HOME=${XDG_CACHE_HOME:-$HOME/.cache}
rm -rf $XDG_CACHE_HOME/paru/clone/hyprland-git

Meanwhile, an obvious downside of cleanbuild is that it performs a full git clone every time. Hence, cleaning should be optional because it's usually unnecessary.

clsty commented 2 weeks ago

I've been using paru to update hyprland-git w/o issues for long. Dunno why cleanbuild is marked necessary here, but I guess it's somewhat related to git submodules.

Thank you for sharing your personal experience. Maybe you are right, but I decide to follow what Hyprland has officially documented.

Or if you're able to make a PR for Hyprland wiki to change their mind, I'll change mine too.

moetayuko commented 2 weeks ago

I've been using paru to update hyprland-git w/o issues for long. Dunno why cleanbuild is marked necessary here, but I guess it's somewhat related to git submodules.

Thank you for sharing your personal experience. Maybe you are right, but I decide to follow what Hyprland has officially documented.

Or if you're able to make a PR for Hyprland wiki to change their mind, I'll change mine too.

Manually remove paru cache is technically equivalent to yay cleanbuild.

clsty commented 2 weeks ago

Meanwhile, an obvious downside of cleanbuild is that it performs a full git clone every time. Hence, cleaning should be optional because it's usually unnecessary.

Tip: You may use --skip-* argument for install.sh to skip specific installation step and update them using your own method.

Manually remove paru cache is technically equivalent to yay cleanbuild.

Thanks. I may take this into consideration. There is just a little problem that actually we also have some other packages that needs cleanbuild to prevent strange bug during/after upgrading. And we need to clean every cache directory for them... You know that the directory name is not always the same as package name, so this is not very elegant. Though I guess it's ok, just need more time on it.

clsty commented 2 weeks ago

For arch(based) distros, I'll replace install-Rubik() directly with aur/ttf-rubik-vf since they actually install the same font files.

Note that the fonts/variable/Rubik*.ttf only includes 2 files from that folder of the repo so it's actually the same as in aur/ttf-rubik-vf.

Also:

Replacing install-Gabarito with aur/ttf-gabarito-git because they actually install same font files.

moetayuko commented 2 weeks ago

Regarding the cleanbuild option, I just noticed the reported issue at https://github.com/end-4/dots-hyprland/blob/2d735947814c9a263460ed5d46a2241dbe719bc1/install.sh#L130, in which yay doesn't upgrade hyprland-git unless cleanbuild.

Essentially this is NOT a bug. yay will not upgrade vcs packages by default unless there's an update on aur. cleanbuild is just a workaround, which removes previously fetched PKGBUILD and thus forcing a new build. The correct approach is documented at https://github.com/Jguer/yay?tab=readme-ov-file#development-packages-upgrade

paru has a similar --devel option to upgrade vcs packages and is enabled in the default /etc/paru.conf, fortunately.

clsty commented 2 weeks ago

Now the only remainder of scriptdata/installers is install-MicroTeX.

But... yeah the aur/microtex-git is not installing LaTeX to /usr/bin/, which means we need to write local PKGBUILD.

However, what about that ./res folder? Are we really installing it as /usr/bin/res/? That's weird and may clash with some other things.

Related: #564 , #559

clsty commented 2 weeks ago

@moetayuko It's actually not much related to current issue. Please talk about it in #627 .

clsty commented 2 weeks ago

@end-4 I begin to doubt that whether res/ folder is neccessary, because normally the resource should be built into a single binary (I guess?). Could you please test that will it still works normally without folder /usr/local/bin/res? (i.e. rename that folder temporarily) Thanks!

end-4 commented 2 weeks ago

it doesn't

clsty commented 2 weeks ago

it doesn't

Ok, in that case the res/ folder is surely needed... But a /usr/bin/res folder is not a good thing either.

Possible (re)solutions:

Inside build() function for PKGBUILD, modify MicroTeX repo to use a different path for res/, e.g. /usr/lib/microtex/.
- Or let the files be together built into a single LaTeX executable.
Install it into another location to avoid /usr/bin/res, in such case we'll need the absolute path for LaTeX executable in .config/ags/modules/sideleft/apis/ai_chatmessage.js. Sure it's acceptable I guess.
...

moetayuko commented 2 weeks ago

it doesn't

Ok, in that case the res/ folder is surely needed... But a /usr/bin/res folder is not a good thing either.

Possible (re)solutions:

* Inside `build()` function for PKGBUILD, modify MicroTeX repo to use a different path for `res/`, e.g. `/usr/lib/microtex/`.

  * Or let the files be together built into a single `LaTeX` executable.

* Install it into another location to avoid `/usr/bin/res`, in such case we'll need the absolute path for `LaTeX` executable in `.config/ags/modules/sideleft/apis/ai_chatmessage.js`. Sure it's acceptable I guess.

* ...

I think installing to /opt makes more sense. I drafted a pkgbuild, feel free to adopt or improve:

_pkgname=MicroTex
pkgname=illogical-impulse-microtex-git
pkgver=r492.d87ebec
pkgrel=1
pkgdesc="A dynamic, cross-platform, and embeddable LaTeX rendering library"
arch=("x86_64")
url="https://github.com/NanoMichael/${_pkgname}"
license=('MIT')
depends=("gtkmm3" "gtksourceviewmm" "tinyxml2")
makedepends=("git" "cmake")
source=("git+${url}.git")
sha256sums=("SKIP")

pkgver() {
  cd $_pkgname
  printf "r%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

build() {
  cd $_pkgname
  cmake -B build -S . -DCMAKE_BUILD_TYPE=None
  cmake --build build
}

package() {
  cd $_pkgname
  install -Dm0755 -t "$pkgdir/opt/$_pkgname/" build/LaTeX
  cp -r build/res "$pkgdir/opt/$_pkgname/"
  install -Dm0644 -t "$pkgdir/usr/share/licenses/$pkgname/" LICENSE
}

Makrennel commented 1 week ago

I think installing to /opt makes more sense. I drafted a pkgbuild, feel free to adopt or improve:

The package manager itself should pretty much never touch anything that isn't in /usr

/opt should only be used by the program itself to install addon stuff at runtime.

Makrennel commented 1 week ago

But... yeah the aur/microtex-git is not installing LaTeX to /usr/bin/, which means we need to write local PKGBUILD.

However, what about that ./res folder? Are we really installing it as /usr/bin/res/? That's weird and may clash with some other things.

Install it to /usr/share/MicroTeX and create symlinks for binaries to /usr/bin, or install the binaries to /usr/bin and patch it so that they look for /usr/share/MicroTeX/res instead of ./res.

end-4 commented 1 week ago

in /opt sounds right to me but i'll let @clsty decide

clsty commented 1 week ago

You know what, I was actually considering /opt too, as some other software are also installed to there, e.g. AList.

Though, same as @Makrennel said, I was thinking about that, is this place really for system package manager? Look, the software I mentioned above are all installed to /opt by running their install script, not by package manager, such as AList.

That's why I didn't mention /opt as a solution. But just now I rechecked Arch Wiki and it has /opt as a recommended directory.

So, yeah, /opt should be the target. @moetayuko I'll borrow your PKGBUILD then, thanks.

clsty commented 1 week ago

Done in f37de4c

end-4 / dots-hyprland

[Enhancement] Deprecate scriptdata/installers for Arch(based) distro #620