search

nikp123 / minecraft-plymouth-theme

MIT License
25 stars 1 forks source link

AUR support #4

Open SilasPeters opened 3 months ago

SilasPeters commented 3 months ago

Hi there!

I love the minecraft GRUB theme, and stumbled upon this repo as well!

Seen as your install.sh is quite simple, I would consider creating a PKGBUILD to turn this repo into a proper package. What are your thoughts on adding this theme to the AUR?

If you agree, I would love to create a first sketch.

nikp123 commented 3 months ago

Sure, I have no problems with it. Go ahead.

SilasPeters commented 2 months ago

Alright I have finished my first draft of a PKGBUILD, but there are some choices which I wish you will consider.

Given that this AUR package will be based on this repo, we have a choice: let the latest version of the AUR package be determined by a git tag, or the latest commit?

My suggestion is that we introduce a dev branch, and that every push on the main branch will trigger a pipeline which updates a PKGBUILD and potentially uploads it. This requires less work, and a dev branch is good practice anyway. However, if we use tags this allows us more control over which version is accesible on the AUR, and then we do not require our aur package to be suffixed by -git. What is your opinion?

Lastly, everything works on my machine with systemd instead of dracut. I will include the config files for dracut anyway, but this might not be as clean. We might want to create a different package for dracut users, but that is overkill.

If you would be so kind to answer these questions, I will soon introduce a fork with potentially some GitHub Actions as well!

nikp123 commented 2 months ago

Given that this AUR package will be based on this repo, we have a choice: let the latest version of the AUR package be determined by a git tag, or the latest commit?

Lets do commits because pushing fixes is easier

My suggestion is that we introduce a dev branch, and that every push on the main branch will trigger a pipeline which updates a PKGBUILD and potentially uploads it. This requires less work, and a dev branch is good practice anyway. However, if we use tags this allows us more control over which version is accesible on the AUR, and then we do not require our aur package to be suffixed by -git. What is your opinion?

This is fine as most people are going to pull master anyway, so to not interfere with that we'll use dev as you suggested

Lastly, everything works on my machine with systemd instead of dracut. I will include the config files for dracut anyway, but this might not be as clean. We might want to create a different package for dracut users, but that is overkill.

No need, we will leave it for VoidLinux users though.

If you would be so kind to answer these questions, I will soon introduce a fork with potentially some GitHub Actions as well!

No problem :)

SilasPeters commented 2 months ago

I finished the first version! I will continue chatting through another account (see next message).

Takstaartje commented 2 months ago

Hi there, it's me again but on my preferred account. Sadly a fork and PR was no use, for the PKGBUILD must be uploaded to the AUR in a separate repo. You can find it on the AUR page (on the right VIEW PKGBUILD).

If you would like ownership of the package, then just tell me your AUR username and I can add you.

I called myself 'maintainer' in the PKGBUILD for I would like to maintain that file.

If I understand the AUR correctly, we do not need to actively update the package version in the AUR whenever there is a new commit, so we don't need to do anything until we change something in the way the package needs to be installed. I might create a 'linter' which checks if the package still works after creating a new commit on the dev branch. The main branch must always work, or the whole package breaks.

Can you create a test commit sometime in the future, where you add a comment in one of the dracut files? Then I can test if updates are recognized.