packages/linux_void
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Template files and build system (public logs available) for https://static.itmodulo.eu/dl/repo/void
6 Commits 1 Branch 0 Tags 57 KiB
799e91c1f7
Go to file
itmodulo 799e91c1f7
All checks were successful
Release xbps for amd64 / compilation-amd64 (push) Successful in 44m48s
Details
Add libcanaberra opt dep to gtkcord4
2024-02-05 22:41:24 +01:00
.gitea/workflows Adapt to xbps-src masterdir-arch breaking changes 2024-01-27 16:27:40 +01:00
srcpkgs Add libcanaberra opt dep to gtkcord4 2024-02-05 22:41:24 +01:00
LICENSE Initial commit 2024-01-27 15:57:03 +01:00
README.md Migrate 2024-01-27 16:06:25 +01:00
shlibs_local Migrate 2024-01-27 16:06:25 +01:00

README.md

Public custom voidlinux repo

Template files and build system (public logs available) for https://static.itmodulo.eu/dl/repo/void

Disclaimer

  1. Don't use this repo if you don't know what you are doing. It may break your great voidlinux experience
  2. I won't upstream this as some packages here may break requirements like git repo has no tags or package may be cutom kernel.
  3. If you want to upstream, go ahead but don't engage me -> You maintain. Although You can reference as working example.
  4. Builds here will be only glibc-x86-64 for now, altough I may consider other variants if you donate me every month
  5. I may rename/remove package without prior notification.

Why

To maintain own repo

Official repo is good quality for desktop usage however:

  • Sometimes your PR is stale for long time
  • According to guidelines they won't include some specific forks
  • You want some feature needed mostly by you
  • Some packages are not released
  • I don't use flatpak for personal reason (mostly size of packages and sdks based mostly on ubuntu I don't really like)
  • Instead flatpaks I use AppImages that are not so easy to update in large quantity
  • Void toolchains are up-to-date

To use repo actions for builds

  • It's easy to maintain
  • Public build logs are more trustowrthy
  • Clear and simple repo structure similar to official one

Builds

  • Built on docker with actions on this repo
  • Signed with private key
  • Triggered on push to release branch
  • Release branch always compile
  • New packages tested on other branches

How does it work

  1. Set up void docker container, instal needed tools
  2. Checkout to some x dir
  3. Replace dir "srcpkgs" from official github to one from this repo
  4. Iterate over its dirs and trigger ./xbps-src pkg
  5. If all succeed, will mount remote path on server
  6. Remove all packages there, clean index
  7. Upload packages
  8. Update index and sign packages with ITmodulo privkey

LICENSE

Actions workflow file and template files are licensed under BSD-3-Clause-no-military

This should not impact the original source code licenses