lure-sh / lure-repo

The default repository for LURE

lure-repo

Documentation: https://gitea.elara.ws/Elara6331/lure/src/branch/master/docs

Web interface: https://lure.elara.ws

lure-repo's Issues

Storage of additional files alongside lure.sh

Just curious: is this not possible currently? obsidian.desktop creation for example is imho horrendous currently and could just be stored as e.g. obsidian/files/obsidian.desktop alongside obsidian/lure.sh and installed to ${pkgdir} from the directory.

For reference on Void's xbps-src this is possible with the ${FILESDIR} global variable.

Documentation for packaging

It would be very helpful for newcomers to have some kind of documentation on how to write build scripts. Most of it is self-explanatory, but unfortunately at least for me not the whole process.

In case this already exists, it would be very helpful to link it to this repo's readme.

lure installed using `lure-bin` package cannot refresh this repo

It's showing me that the version number is lower than specified in the repo. Indeed, lure version returns 0.0.4-* instead of 0.0.5. lure-git works as expected.

[RFC] Rules for extremely long lines in lure.sh files

As an example I was looking at the admc package and the deps_amd64 line is 431 characters long which in my eyes is absurd; not only do you have to scroll a lot horizontally on any device but you absolutely need wordwrap in a text editor to even see it all at a glance!

What would be a fine limit? I think 80 might be a bit too much and would cause many "unnecessary" line breaking everywhere, so maybe 100+ characters limit before lines should be wrapped with a newline, so maybe 120? 160?

Just having some character limit (for situations where it's possible to wrap with newlines) which everything follows would be great to have for the sake of readability :)

[RFC] Consistent style for commit titles

I do rather like how the commits to void-packages are done, would it be too much of a hassle for contributors to start using something consistent? I propose these commit titles:

• Adding a new package: ${name}: new package (${version})
  • Example: strelaysrv: new package (1.18.6)
• Updates to existing package: ${name}: update to ${version}
  • Example: strelaysrv: update to 1.22.1
• Other changes to a package: ${name}: some other changes, enable feature, ...
  • Example: strelaysrv: fix cheksums

The important thing is the ${name}: prefix on each commit title, even on updates you could suffix it with , something else if it's important enough to state in the commit title. The extended commit message itself would still be free-form.

Having the titles standardized would make the commit history nice to read and you can tell at a glance what is going on in each as well :)

Discord update to 0.0.27

Stop linking to the old gitea

On the first line after the header on the readme their is a link to the gitea repo which has moved to GitHub as I understand