Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Suggestion] Add more details about YAP PKGBUILD spec file #25

Open
M0Rf30 opened this issue Mar 16, 2022 · 1 comment
Open

[Suggestion] Add more details about YAP PKGBUILD spec file #25

M0Rf30 opened this issue Mar 16, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@M0Rf30
Copy link
Contributor

M0Rf30 commented Mar 16, 2022

Is your feature request related to a problem? Please describe.
We need to extend some details about the PKGBUILD rules

Describe the solution you'd like
Add details about:

  • the backup path (absolute or relative?)
  • highligh differences between yap and arch PKGBUILD

Describe alternatives you've considered

  • remove the differences: parsing directly arch PKGBUILD, move to another filename (these are breaking changes)
@M0Rf30 M0Rf30 added the enhancement New feature or request label Mar 16, 2022
@M0Rf30
Copy link
Contributor Author

M0Rf30 commented Jun 11, 2022

In these days I deeply think about extreme semplification of the overall logic.
Questions like:

  • how to manage the spec definition?
  • does it make sense to be non-compliant with Arch PKGBUILD?
  • how to rewrite an efficient parser without going crazy?
  • which token to use to determine different distro scopes? (nowadays we use :)

and the answer is the obvious and rock-solid: Keep it simple stupid and let's parse simple BASH spec files, making yap fully compliant with Arch PKGBUILD

This consideration answers to the first 3 questions in a very simple way:

  • yap PKGBUILD == Arch PKGBUILD
  • no
  • plenty of high quality pure-go bash parser out there
  • double underscores __, doesn't break syntax checkers or shell linters

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant