You are not logged in.
Is there an idiomatic way to debug PKGBUILDs which uses VCS as `source`?
I mean debugging without checking-in intermediate sources into the VCS and/or temporary hacking `sources` variable.
Last edited by serzh-z (2019-01-20 01:28:33)
I woke up in my bed today - a hundred years ago. Who am I? Who am I...
Offline
I know it is not what you asked for, but I have always just added the "#commit=...." to the end of the source.
Offline
I know it is not what you asked for, but I have always just added the "#commit=...." to the end of the source.
It makes sense in some cases but actually, it will do not ease the debugging.
Let me explain the process:
I actively edit sources and want to repeat makepkg/install/test steps. Now I have two options:
- Commit and push every source change and then build/install package.
- Write 'debug' variant of PKGBUILD which will use a local directory instead of remote VCS.
I am wondering if there is an ability to specify makepkg some kind of 'temporary use a local directory instead real remote VCS'. Right now it is an ass-pain to debug such PKGBUILDs.
I woke up in my bed today - a hundred years ago. Who am I? Who am I...
Offline
`makepkg -e`
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
`makepkg -e`
Oh, thanks! I was too lazy to look into the man.
I woke up in my bed today - a hundred years ago. Who am I? Who am I...
Offline
You may find https://wiki.archlinux.org/index.php/Bi … s_with_Git interesting.
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
(A works at time B) && (time C > time B ) ≠ (A works at time C)
Offline
You may find https://wiki.archlinux.org/index.php/Bi … s_with_Git interesting.
Yeah, it will be useful.
BTW, is there an idiomatic way to store PKGBUILDs?
I meant the following:
- Using a single separated repo with a lot of arbitrary PKGBUILDs like it does, for instance, Eli Schwartz in https://github.com/eli-schwartz/pkgbuilds
- Placing PKGBUILD in the same repo where application sources live (and point `source` variable to this repo)
- Just using an AUR package repo as a PKGBUILD primary repo
- Something else
Last edited by serzh-z (2019-01-20 14:36:14)
I woke up in my bed today - a hundred years ago. Who am I? Who am I...
Offline
BTW, is there an idiomatic way to store PKGBUILDs?
No. But your list covers many of the good options. Use whichever works best for you.
Persoanlly, I tend to keep PKGBUILDs for projects I've created with the code I'm creating. That way if any code changes require PKGBUILD changes, it's right there in the same project directory (generally in a "packaging" or documentation related sub directory).
For PKGBUILDs I keep where I'm not also the sole or primary author of the source code, I just keep a tree much like eschartz's.
Last edited by Trilby (2019-01-20 14:36:40)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
serzh-z wrote:BTW, is there an idiomatic way to store PKGBUILDs?
No. But your list covers many of the good options. Use whichever works best for you.
Got it. Thanks.
I woke up in my bed today - a hundred years ago. Who am I? Who am I...
Offline