<jaeger>
pkgmk diff and kodi Pkgfile using nounpack=()
<jaeger>
the last change in the pkgmk diff is a linter fix, not part of my stuff
<farkuhar>
jaeger: looks like the linter only concerned itself with indentation, and failed to suggest s/egrep/grep -E/ (the change you recently applied to httpup-repgen).
<farkuhar>
arguably it's not the job of a linter to be aware of the syntax for every command in your script; that's what we have shellcheck for.
<jaeger>
yeah... but thanks for pointing it out, I might go back and change that as well
<jaeger>
but if anyone wants to test the nounpack thing, let me know if you run into any problems
<jaeger>
Regarding the renames array requiring all elements of source, we could probably add a little logic to solve that as well... such as an index, like 1:filename
<jaeger>
or filename:newfilename
farkuhar has quit [Ping timeout: 252 seconds]
farkuhar has joined #crux-devel
<farkuhar>
jaeger: http://ix.io/4jS3 is a small refactoring of your latest pkgmk diff. It consolidates into one function the tests for what gets unpacked, rather than distributing the tests between a subroutine and a case...esac construct.
<farkuhar>
feel free to ignore the build_package() change, that was leftover from a discussion with braewoods and groovy2shoes about faster seeking through the compressed package.
<jaeger>
Looks fine to me, figured it could probably be done better
<farkuhar>
Tidying up the renames array (so you don't have to specify SKIP or new_name for every element of source) might introduce some breakage during the transition from the current versions of pkgmk and prt-utils. I recommend waiting until the next major CRUX release, if we're going to rethink how Pkgfiles get parsed.
<jaeger>
of course
<farkuhar>
The way it's done now, iirc, is what Romster suggested in one of the earliest replies to FS#923.
<farkuhar>
There were competing proposals even back then, including the use of associative arrays (demonstrated by Fun in upkgmk), but Romster's suggestion seemed the most portable (not as reliant on bash-specific features).
<jaeger>
I didn't really follow it as it's not a feature I've needed
<farkuhar>
Consider all the one-off hacks that folks have put in their Pkgfiles and in pkgmk.conf, relying on shell expansions and command substitutions. Example here: https://lists.crux.nu/pipermail/crux/2011-March/002748.html That might be why we implemented tarball renaming using the most portable suggestion, rather than taking an approach that would confuse a parser not written in bash.