Arch Linux

> makedepends=('git' 'cmake' 'file' 'make' 'gawk' 'gcc' 'zsh' 'wget')

Members of `base-devel` package group (`file`, `make`, `gawk`, `gcc` shouldn't be added to `makedepends`.

Fixed. New PKGBUILD: https://github.com/romkatv/archlinux-community/blob/b0bc03c59174f881566e9e9044c957c9d4b0179c/zsh-theme-powerlevel10k/trunk/PKGBUILD

While the PKGBUILD in Community may need some changes, ./gitstatus/build is not a solution. That script is TERRIBLE for packaging.

Is it possible to remove the package then? The current situation is awful for the users (they get broken software) and for me as the upstream owner (I get bug reports I can do nothing about).

please be patient, I will fix this issue as soon as I have time for it. As I explained in the issue, I will not execute scripts during build() that side-load other sources. This is bad practice and breaks any security measures (isolated build environments) or reproducible builds. All needed content should be transparently listed in the source array.

What was wrong with the old way?

I suggest the following:

You keep updating gitstatus + powerlevel10k.
Also you should tag gitstatus with the powerlevel10k version, so we can make sure that we pick the right gitstatus with the correct powerlevel10k. I really don't want to iterate through different gitstatus commits for checking if it works with powerlevel10k version XY.

> I will not execute scripts during build() that side-load other sources. This is bad practice and breaks any security measures (isolated build environments) or reproducible builds. All needed content should be transparently listed in the source array.

When `./gitstatus/build` is invoked with `-w` flag, it will download the appropriate libgit2 tarball (a dependency of gitstatus) and verify its SHA hash. This is as secure and as reproducible as any build. However, as I mentioned earlier, and as documented in the packaging instructions, you can download libgit2 tarball manually and not pass `-w` to `./gitstatus/build`. I've modified PKGBUILD to do that.

Diff against the previous version (the one with `-w`): https://github.com/romkatv/archlinux-community/commit/eb3d2051e489fa875135b4e76efab2ff80c3181c#diff-a1a099bd4ba4e9cae36cc252c4d95269
New PKGBUILD (without `-w`): https://github.com/romkatv/archlinux-community/blob/eb3d2051e489fa875135b4e76efab2ff80c3181c/zsh-theme-powerlevel10k/trunk/PKGBUILD

Edit: fixed both links.

The new version of PKGBUILD lists two tarball sources. They must be updated simultaneously.

If the new PKGBUILD is not up to your standards, please do let me know.

> What was wrong with the old way?

There has been two old ways in zsh-theme-powerlevel10k community package.

The first old way (until v1.8.0) was to download a dozen of compiled binaries during the build of the package. All these binaries would end up in /usr/share when the package is installed. Only one of them was used. The rest were for other operating systems and/or architectures. This kind of packaging had two downsides: 1) downloading compiled binaries is against Arch Linux packaging guidelines; 2) the size of the installed package was an order of magnitude greater than it should've been.

The second old way (starting from v1.8.0) was to not package any binaries and instead package an installer. When such package was used for the first time, the installer would download a compiled binary for the appropriate OS and architecture. This had two downsides: 1) packaging an installer that downloads compiled binaries is against Arch Linux packaging guidelines; 2) downloading anything on first use is worse UX than doing it during package installation.

The new way is to download source tarballs, compile gitstatus and package it.

> You keep updating gitstatus + powerlevel10k.

You can count on that.

> Also you should tag gitstatus with the powerlevel10k version

The fact that powerlevel10k has an embedded gitstatus is an implementation detail. If you follow the packaging instructions for powerlevel10k and gitstatus, both packages will be able to peacefully coexist on the same machine. The embedded gitstatus in powerlevel10k will not clash with the standalone gitstatus package. They even can have different versions. Those different versions can even be used from the same shell. The embedded gitstatus in powerlevel10k can only be used by powerlevel10k. In short, users and packagers of powerlevel10k shouldn't care that it uses/embeds gitstatus.

> I really don't want to iterate through different gitstatus commits for checking if it works with powerlevel10k version XY.

That's good. Packaging instructions for powerlevel10k say that you must not do that. You must not attempt to create a package for powerlevel10k, another package for gitstatus, and introduce a dependency between them (creating both packages is fine; the dependency is not). You shouldn't care at all that powerlevel10k uses/embeds gitstatus. Treat these projects as completely independent.

Hello Roman,

this still needs a lot more love from your and our side.

1. the gitstatus binary is not being build with our LDFLAGs. Therefore our security enhancements like FULL RELRO and PIE are missing.

2. the PKGBUILD is shipping unnecessary files, like the src of gitstatus or a .vscode config file etc. So we need a lot more cleanup here.

3. I propose strictly split build() and package(). So the for loop that installs everything should be in the package() function and not in build().

4. Also it would be nice if you could sign your tarballs with a GPG key.

> this still needs a lot more love from your and our side

You are putting me in a difficult spot. The current version of zsh-theme-powerlevel10k was created without my involvement and contrary to the packaging instructions that I've published on the project homepage and shared with you personally. The package has several serious shortcomings. It does not package any binaries and instead packages an installer. When zsh-theme-powerlevel10k is used for the first time, the installer downloads a compiled binary from github.com. This binary is not signed with a GPG key. It's not compiled with LDFLAGS that you prefer. It's not compiled against glibc. It's not even compiled on Arch Linux. Moreover, the installer packaged by zsh-theme-powerlevel10k has bugs that had since been fixed in the upstream project. Since zsh-theme-powerlevel10k is not getting updated, these bugs keep affecting Arch Linux users. Despite my adding a notice on the homepage of powerlevel10k to avoid zsh-theme-powerlevel10k package, I'm still receiving ~1 bug report per day from Arch Linux users.

I understand that the new PKGBUILD that I've prepared is not up to your standard. However, all criticism applies to the current version of the package as well. Try to see how it looks from my point of view. I've never asked you to package my project. You've packaged it in a way that doesn't work. My users are screwed and I'm the one getting bug reports. When I attempt to fix the broken package, you demand that I fix **all** its issues. That's a pretty awful situation to be in. I'd be much more comfortable discussing potential packaging improvements if the current version wasn't causing ongoing damage.

The current version of zsh-theme-powerlevel10k is actively harmful to Arch Linux users. They would be better off if this package didn't exist. I'm urging you to fix this package or delete it.

we dont need to ask upstream to package software and we are not a toy distro that uses bundled installers that download arbitrary software from the internet. I understand your situation but this is something that needs to be worked on on both sides and not just demanding to delete it and make bold and irresponsible claims to not use the Arch Linux package.

If you want to improve the situation, try to work with the packager here and the requires is quite sane: build the dependencies from source during package build and not to use an installer that downloads pre built binaries.

The **current version** of zsh-theme-powerlevel10k, the one that gets used by `pacman -S zsh-theme-powerlevel10k`, is placing an installer in `/usr/share/zsh-theme-powerlevel10k`. This installer downloads a compiled unsigned binary from github.com. This is quite awful. I'm asking the package maintainer to either please fix this or remove the package.

Yes, thats correct. so lets all work together to get this resolved and concentrate on the solution, not the problem

Yeah, let's.

My suggestion is to either fix the package or, if it's not feasible given the quality of upstream project, remove it. WDYT?

dude get yourself together, you are the "quality of upstream project" so how about working together to get it in an appropriately packagable state? Shibumi is right now working on it but he may be forced to propose changes on your build scripts to make that work. Its much more productive for all of us we we _all_ are productive and positive minded to get stuff resolved into a state that suites _all_ needs, which isn't anything impossible but a sheer question of will.

> Shibumi is right now working on it

Thank you for providing information! This is actually useful.

@romkatv: You're welcome. Somehow this whole thing de-railed while both of you worked on it and I'm trying to pull the strings together so everyone of us will be happy at the end. happiness is important :D

So,
I have some good news. I have a working PKGBUILD right now that fixes our security concerns: https://paste.xinu.at/GQdx/
However It's throwing this error when I start the zsh-theme:

[ERROR]: gitstatus failed to initialize.

it looks like `gitstatus_start` is not known. At least I can't execute it. When I execute gitstatusd directly with the mentioned flags it seem to work.

@Roman can you have a look on the files I am deleting in the PKGBUILD? I am not sure if I need to cleanup all of this files. You have mentioned an install file. When I delete this `gitstatus/install` file, the zsh-theme works as expected, but I think it's sideloading the binary.

If you need further input, feel free to ask me.

> @Roman can you have a look on the files I am deleting in the PKGBUILD?

If you delete any files, things can break. I don't provide any guarantees about powerlevel10k if some of the files are deleted. (I don't suppose Arch Linux provides any guarantees of this sort?) There is no easy way to figure out whether things work or not if you delete a file. There may be no error on initialization but then an error some time later. You are obviously free to delete files but please make it clear to your users that bugs should be filed to bugs.archlinux.org.

May I ask why you want to delete files? It's not to save space, is it? These files take less than 1% of the package size.

The same goes for custom compilation flags. I test everything *only* with compilation flags in the build script. If you use your own, you'll need to do your own testing and handle bug reports. The alternative is for you to tell me which flags that are currently used by the build script you don't want to be passed and which ones you do want. I can change the script.

If you don't want to invoke the build script but are OK with invoking make, then can you clarify the difference? Make is the same sort of script. It's bash with some dependency tracking.

> [ERROR]: gitstatus failed to initialize.

This is likely caused by missing files.

double comment.. sorry

@roman I was asking because you said earlier:

> The **current version** of zsh-theme-powerlevel10k, the one that gets used by `pacman -S zsh-theme-powerlevel10k`, is placing an installer in `/usr/share/zsh-theme-powerlevel10k`

Can you specify which file is the installer? The PKGBUILD is not so different to yours, the only changes we do are:

1. we don't use your build script
2. we use all of your CMAKE flags. The only exception is "-DENABLE_REPRODUCIBLE_BUILDS=ON"
3. We set our own LDFLAGS and CXXFLAGS additional to yours and we don't build gitstatusd static (this is not necessary, because we can utilize the package manager for dependency management.

With this changes gitstatusd on Arch Linux has increased security:

```
❯ checksec --file=gitstatusd
RELRO STACK CANARY NX PIE RPATH RUNPATH Symbols FORTIFY Fortified Fortifiable FILE
Full RELRO Canary found NX enabled PIE enabled No RPATH No RUNPATH No Symbols Yes 6 17 gitstatusd
```


About deleting files:

There is no reason for shipping gitignore, gitattributes or object files or even the source code in /usr/share/.

Can you tell me which of these files are necessary for zsh-theme-powerlevel10k to work properly?

/usr/share/zsh-theme-powerlevel10k/gitstatus/build
/usr/share/zsh-theme-powerlevel10k/gitstatus/build.info
/usr/share/zsh-theme-powerlevel10k/gitstatus/install
/usr/share/zsh-theme-powerlevel10k/gitstatus/install.info
/usr/share/zsh-theme-powerlevel10k/gitstatus/deps
/usr/share/zsh-theme-powerlevel10k/gitstatus/Makefile
/usr/share/zsh-theme-powerlevel10k/gitstatus/mbuild

These are the one I am deleting additional th the obj direcctory, the src directory and git specific files that are not necessary.
Can you please just tell me which of these files I can't delete?

> If you don't want to invoke the build script but are OK with invoking make, then can you clarify the difference?

Sure, your build script is not suitable for us, because:

1. it overwrites our compiler flags
2. it makes the build process unnecessary complicated, when problems occcure.
3. it invokes commands such like `pacman -Syu --noconfirm` that changes our build environment

Why not just providing a documentation for distributions with the easy steps I have provided you via the PKGBUILD? I am aware that these steps are different for building with homebrew, but at least it's compact and distribution packagers don't need to read your build script. The build script is hiding the important parts.

Btw, why not shipping gitstatusd in /usr/bin/? Is this possible? If so, how would I do this?

@romkatv,

You already build libgit2 statically with -DBUILD_SHARED_LIBS=OFF, and the only other dependency is libc. There is really no reason to add -static, as its only purpose is to allow running the program on systems with an older version of glibc than the build environment, when distributing static binaries to users of many distros. The traditional way to accomplish this is NOT using -static, but rather, using a build container as old as the oldest version of glibc you wish to support. (You can build in a CentOS 6 docker container if you want to support essentially every system in existence, since CentOS 6 uses glibc 2.12 and I don't think anyone anywhere still uses anything older than that.)

Arch Linux declines to statically link libc in packaged software; this is not up for discussion, sorry. Additionally, we wish to use compilation flags such as:

CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

and allow users to tune these to e.g. set -g/-ggdb if debug packages are used, or internally use gcc's -fdebug-prefix-map to rewrite source path names in the debuginfo sections when packaging split debug info with source files included.

I will be utterly shocked if our use of specific -O levels, or the fact that we add hardening flags such as RELRO, causes your software to break. I will be several levels beyond shocked if our use of -fdebug-prefix-map causes your software to break. But if it does break, then you, not us, have done something badly wrong. I'm not aware of any other software that breaks willy-nilly as a result of such flags.

As shibumi said, w.r.t. *configuring* libgit2, as opposed to compiler flags, we are changing things, but we are not doing so willy-nilly, we are merely telling libgit2's CMakeLists.txt via -DENABLE_REPRODUCIBLE_BUILDS=ON to configure /usr/bin/ar to include the "D Operate in deterministic mode." flag, which again is so uncontroversial as to be I-don't-even-know-why-this-might-be-fathomed-to-be-a-problem.

...

We are indeed happy to handle bug reports if our CFLAGS do break, just like we do for all software in our repos, this package isn't special in that regard.

If you'd like to enable the libgit2 reproducible `ar` mode, that would be nice, if you'd like to allow passing through our CFLAGS/LDFLAGS, that would be nice too. Otherwise, we'll keep on reimplementing the build ourselves, which may be made more complex if you don't provide documentation on how to build without your "./gitstatus/build" script.

After upgrading to 1.10.1-1, and running p10k configure to generate the config, I get this error,

--
[ERROR]: gitstatus failed to initialize.
Your Git prompt may disappear or become slow.
Run the following command to retry with extra diagnostics:
GITSTATUS_LOG_LEVEL=DEBUG gitstatus_start POWERLEVEL9K
--

'gitstatus_start' does not exist, however,

$ type gitstatus_start_p9k_

gitstatus_start_p9k_ is a shell function from /usr/share/zsh-theme-powerlevel10k/gitstatus/gitstatus.plugin.zsh


I get no such error using the manual install method (git clone from p10k GH repo).

Thanks Dean and sorry for abusing community as test bench for this release.

I hope romkatv can explain us why `gitstatus_start` is missing. The gitstatusd binary looks fine for me, it starts as expected and doesn't throw any errors.
So it must have something to do with the zsh files.

I'm not sure how much of this is already known, @Shibumi, so I apologise if so. I also upgraded to 1.10.1-1, but I get the "gitstatus failed to initialize" error every time I open a new terminal. The previous version and the AUR package work fine. Would it be preferable to have a working (if out-of-date) version in the repos, until this is fixed?

> type gitstatus_start_p9k_ gitstatus_start_p9k_ is a shell function from /usr/share/zsh-theme-powerlevel10k/gitstatus/gitstatus.plugin.zsh

How do you get this reference to p9k coming from a p10k package?

...

gitstatus_start is defined in /usr/share/zsh-theme-powerlevel10k/gitstatus/gitstatus.plugin.zsh using some odd indirection that permits the function name to be suffixed with "${1:-}", apparently.

In /usr/share/zsh-theme-powerlevel10k/internal/p10k.zsh it does this:

source $gitstatus_dir/gitstatus.plugin.zsh _p9k_ || return

so the function name is apparently intended to be gitstatus_start_p9k_ for inexplicable reasons, the entire powerlevel10k framework seems to internally parameterize itself in order to call itself "p9k", the docs are wrong, the diagnostic errors are wrong and you should try running

GITSTATUS_LOG_LEVEL=DEBUG gitstatus_start_p9k_ POWERLEVEL9K



(Why does zsh permit variable dereferencing midway through function name declaration? This should be a federal crime.)

@Moabit sorry for the inconvenience. I hope upstream will help fixing this issue soon.
About your questions: The last fully working version was 1.7.0 (that version had a precompiled binary).

It's theoretically possible to ship the `install` script again. Then our 1.10.1 package in the repos would work, because it would sideload a gitstatusd binary into your $HOME, but I really don't want to do this. Sideloading is awful, a security risk and I don't want to support such "features".

Upstream should fix this `gitstatus_start` bug. Our gitstatusd binary is working as expected, I think the issue for the failed initialization lies in some ZSH voodoo and I hope upstream aka @romkatv can give us a hint, why it's failing.

@Shibumi No worries, I understand that it's a complicated issue. However, what would you recommend end users do? Should revert/pin the old version in the meantime? Or should this semi-broken version be in testing instead?

Okidoki. I only mention gitstatus_start_p9k_ as that's the nearest thing that came up with a 'gitstatus<tab>'.

I ran GITSTATUS_LOG_LEVEL=DEBUG gitstatus_start_p9k_ and got https://0x0.st/ip3M.txt

I'm bit of an idiot, but, I think "no such file or directory: /usr/share/zsh-theme-powerlevel10k/gitstatus/install"
has something to do with it.

It seems like the files gistatus/install gitstatus/install.info and gitstatus/build.info are needed to locate the compiled binary. I've edited the PKGBUILD to not remove them and everything works fine, while 'ps -o command' shows that the packaged gitstatusd is running instead of some downloaded one.

As a side note, I have other feedback about the new PKGBUILD
1. It removes some dotfiles but many are left, I don't think this is intended?
pacman -Ql zsh-theme-powerlevel10k | grep -E '/\.'

2. It precompiles some zsh code at the end of package(), but it does so in source directory, so the precompiled scripts (.zwc files) aren't packaged.

I hope it helps

> Can you specify which file is the installer?

There is no dedicated file that is the installer. When gitstatus starts, it checks if there is gitstatusd available locally. If there isn't, it downloads one from GitHub releases. zsh-theme-powerlevel10k v1.8.0-1 has been packaged without gitstatusd, hence it essentially contained an installer that triggers on first use.

> we use all of your CMAKE flags. The only exception is "-DENABLE_REPRODUCIBLE_BUILDS=ON"

I've checked why I had this feature turned off. The reason is that it's not supported on some architectures for which I distribute gitstatus. I've modified my build script to enable it everywhere where it empirically works.

> We set our own LDFLAGS and CXXFLAGS additional to yours and we don't build gitstatusd static (this is not necessary, because we can utilize the package manager for dependency management.

Sounds good. I've modified my build script to use the same optimization and hardening flags you use when compiling on platforms that support them.

> Can you tell me which of these files are necessary for zsh-theme-powerlevel10k to work properly?

As of v1.10.1, the following is a minimal list of files that are necessary for powerlevel10k to work correctly.

./config/p10k-classic.zsh
./config/p10k-lean-8colors.zsh
./config/p10k-lean.zsh
./config/p10k-pure.zsh
./config/p10k-rainbow.zsh
./config/p10k-robbyrussell.zsh
./gitstatus/build.info
./gitstatus/gitstatus.plugin.zsh
./gitstatus/install
./gitstatus/install.info
./gitstatus/usrbin/gitstatusd-linux-x86_64
./internal/configure.zsh
./internal/icons.zsh
./internal/p10k.zsh
./internal/parser.zsh
./internal/wizard.zsh
./internal/worker.zsh
./powerlevel10k.zsh-theme
./powerlevel9k.zsh-theme
./prompt_powerlevel10k_setup

This list doesn't include *.zwc files that improve startup performance but aren't strictly necessary.

Empty directories aren't necessary.

Note that this list may change in the next release and this won't be communicated through any channel. If you must delete some files, use your own judgement to guess how safe it is to delete each specific file.

> [the build script] invokes commands such like `pacman -Syu --noconfirm` that changes our build environment

Only on Windows via MSYS2 and only when you explicitly pass `-s` to the build script.

> Why not just providing a documentation for distributions with the easy steps I have provided you via the PKGBUILD?

It's extra work for me that I don't want to take on at the moment.

> Btw, why not shipping gitstatusd in /usr/bin/?

gitstatusd (the binary) doesn't have a stable API. It's useless on its own.

> There is really no reason to add -static

I'm using the build script for my own distribution that's used by the vast majority of powerlevel10k users. When targeting Linux, it links against musl so that the binary works on systems without glibc. A significant portion of powerlevel10k users are on such systems. The biggest of them is Android, although desktop Linux distros without glibc are also getting popular (e.g., Alpine). I realize that for Arch Linux -static doesn't make sense. It doesn't even remove the runtime dependency on glibc. I've modified the build script to not use -static when compiling locally.

> we'll keep on reimplementing the build ourselves, which may be made more complex if you don't provide documentation on how to build without your "./gitstatus/build" script.

Sounds good.

I cannot commit to providing the documentation you are asking for. To avoid confusion, I've removed the existing packaging instructions from Powerlevel10k and gitstatus documentation and replaced them with the following:

> It's currently neither easy nor recommended to package and distribute
> Powerlevel10k. There are no instructions you can follow that would allow
> you to easily update your package when new versions of Powerlevel10k are
> released. This may change in the future but not soon.

I realize that the current state of Powerlevel10k and gitstatus is far from ideal for the purpose of packaging. The passage quoted above acknowledges it and sets correct (low) expectations.

> sorry for abusing community as test bench for this release.

You've knowingly pushed a broken package which has broken the shell of many users and caused a flood of bug reports to upstream. This is not nice at all.

If I keep getting bug reports from Arch Linux users that result from incorrect packaging, I'll add a clause to the license that requires distributions to use a different package name that cannot be confused with the upstream project. It's not something I want to do but at this point I'm spending a disproportionate amount of time handling your bugs and I don't want my project's name be associated with what you package.

> I hope romkatv can explain us why `gitstatus_start` is missing.

I replied yesterday: "This is likely caused by missing files."

See the full list of required files above.

> How do you get this reference to p9k coming from a p10k package?

Powerlevel10k is a fork of powerlevel9k. See: https://github.com/romkatv/powerlevel10k/blob/master/README.md#What-is-the-relationship-between-powerlevel9k-and-powerlevel10k.

> Upstream should fix this `gitstatus_start` bug.

Bugs in powerlevel10k should be reported to https://github.com/romkatv/powerlevel10k/issues. Make sure you are using a supported installation method before you do so.

In a few places above I mentioned that I've changed the build script to use the same flags as Arch Linux. This is not meant to convince you to use my build script. I mentioned it to let you know that gitstatusd compiled with these flags is now being tested by myself. It doesn't imply, however, that I'll be monitoring Arch Linux for future flag changes.

@Moabit, @Dean, @Robert

Can you install the newest package version? It should fix all your issues now. I have tested it and works for me. I get no "gitstatus failed initialization" errors anymore.

@Robert

Thanks for the list of hidden files. I will delete them in the next release
I just wonder about `/usr/share/zsh-theme-powerlevel10k/gitstatus/usrbin/.gitkeep` What is gitkeep? Is this necessary for the prompt, too?


@romkatv

All of this could have been solved if you would have provided the same what we worked on in the last 2 days in a short README.
If you like I can contribute a "Linux Distribution Packager Guide" for your project. It should include:

1. Files that are essential for the project
2. Files that can be safely removed
3. A way to build your project without using the build script (A summary for the build flags, how to compile gitstatus with enhanced security measures etc)
4. Modifications like compiling the zsh sources.

> All of this could have been solved if you...

Just to remind you the events that has led to this disaster.

1. You've packaged my project against the Arch Linux packaging guidelines. Your package was bundling a dozen of compiled unverified binaries.
2. I've made changes to my project and have contacted you to let you know that your package needs to be updated before you can release a new version. Note that you've never contacted me. I just saw that you've packaged my project and wanted to give you a heads up.
3. You've ignored my message and released a new version with no packaging changes. This time your package wasn't bundling any compiled binaries but was instead bundling an installer that downloads a compiled unsigned binary on first use.
4. 12 days later I was fed up with bug reports from Arch Linux users so I've opened this issue.

I'm not asking you to maintain this package. I don't care if it exists or not. Just don't publish garbage under the name of "powerlevel10k".

> I can contribute a "Linux Distribution Packager Guide" for your project.

No thanks.

@Christian
.gitkeep files are used to force git to keep track of an otherwise empty directory. I'm sure it's not needed.

Anyway, the *-2 version works for me, thanks!

@Shibumi 1.10.1-2 works for me now. Thank you.

romkatv: you are a truly ill minded here and purely focused on playing the victim role instead of getting things sorted without throwing poo around and be a responsible upstream that also takes distro perspective into account. This could have been solve much easier if you wound't act like this, i have tried putting this derailed working together into track again without being biased at all who was correct or not, but you work quite hard on keeping this artificially derailed.

> This could have been solve much easier if you...

Mkay.

@romkatv

I agree with your statements. It could have been way better if I would have answered you, when you were so kind to highlight me and ask me for my opinion about your distribution guide. However, I am doing this in my free time (as you are maintaining powerlevel10k in your free time), I just can't be everywhere every day. I just have 24 hours per day + more packages that need even more time than yours. You are correct with the fact that we have bundled binaries in the past, but we fixed this from now on.

Besides all of this, I don't like that you use the word 'garbage' for our PKGBUILD. It provides your package bundled in less than 100 lines + enhances your project with several security flags + cleans up the final directory in /usr/share/.

Use your time for something better than yelling at downstream for not following your packaging guidelines.

I think we did a good job here. The package is working, users are happy that they can install via pacman and the shipped software is now more secure than before. Your project even benefit from it (enhanced compiling flags in the build script).

With the latest pkgbuild (-3) it also builds the libgit2 fork with our compiling flags + it removes more clutter.

Even if you don't like this, but actually this is a win-win situation for both of us.

I am closing this ticket for now, because everything has been fixed.

From https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD:

> # unfortunetaly this is necessary. Otherwise gitstatus/install will try to
> # sideload the gitstatus binary and place it in $HOME/.cache/gitstatus/
> mv "${pkgdir}/usr/share/zsh-theme-powerlevel10k/gitstatus/usrbin/"{gitstatusd,gitstatusd-linux-x86_64}

This comment is misleading. It's not necessary to rename the binary and gitstatus/install will not try to sideload anything.