[pacman-dev] makepkg enhancements: globstar and variable expansions in PURGE_TARGETS, MAN_DIRS, etc.

[Ciprian Dorin, Craciun]

On Sat, Nov 14, 2009 at 10:02 AM, Ciprian Dorin, Craciun
<ciprian.craciun at gmail.com> wrote:
> On Sat, Nov 14, 2009 at 8:44 AM, Allan McRae <allan at archlinux.org> wrote:
>> Ciprian Dorin, Craciun wrote:
>>>
>>>    Hy everybody!
>>>
>>>    While building some custom packages for a stripped down Linux
>>> server, I've hit the following problems:
>>>    * the cause of the problems is from the pact that my packages are
>>> each in it's own folder like: /packages/bash--4.0--1,
>>> /packages/busybox--1.15.2--1, etc., and thus,
>>>    * MAN_DIRS, DOC_DIRS, STRIP_DIRS and PRUNE_TARGETS doesn't work,
>>> as I have no way to use ${pkgname}, etc in there;
>>>    * in PRUNE_TARGETS there is no way to specify file patterns (like
>>> '*.a', or '*.la'), but only from certain folders; (for example I can
>>> say '*.a', but not '../lib/*.a'; also I can not specify unknown number
>>> of parents, like '.../lib/**/*.a';
>>>
>>>    As a consequence, I propose (and if accepted I also have the
>>> patches for) the following enhancements:
>>>    * allow the patterns in MAN_DIRS, etc. to be evaluated at the
>>> proper time execution time (when we access MAN_DIRS), not at
>>> configuration time (when we define MAN_DIRS); this can be achieved by
>>> (single) quoting the patterns like:
>>> 'package/${pkgname}--${pkgver}--${pkgrel}/{,share/}man' and then
>>> expansion by using eval;
>>
>> You can use
>>
>> MAN_DIRS=({package/*/,}{usr{,/local}{,/share},opt/*}/{man,info})
>>
>> and that will work.  An eval statement is evil.
>
>    I don't know this for sure, but I assume that the makepkg.conf
> file is sourced before actually going to build or package. Thus in
> order for `package/*/` to work it must already exist in the current
> folder.
>
>    For example I've searched makepkg.sh for where the config file is
> read, and I've found that it's hold in the MAKEPKG_CONF variable. And
> the only place it's sourced is just before executing anything. This
> means that (maybe) my previous assumption is right, and that
> `package/*` or `opt/*` doesn't work.
>
>    I agree that `eval` is evil. (If you ask me Bash is the most evil
> programming language from them all, but I still do about 25% of my
> programming in Bash...) So coming back to eval, in order to make my
> use-case happen we have two options:
>    * either we source MAKEPKG_CONF before each operation,
>    * or we use eval on our patterns, and we single quote the patterns
> in the config file;
>
>
>>>    * allow enhanced pattern types for PURGE_TARGETS, like:
>>>        * the same lazy evaluation as above;
>>>        * if a pattern starts with '=' then it must exactly match a file
>>> name;
>>>        * if a pattern starts with '+' then it is a glob pattern (or
>>> globstar), like:
>>> 'packages/${pkgname}--${pkgver}--${pkgrel}/lib/**/*.a'
>>
>> These seem to be able to be handled in much the same way as MAN_DIRS above.
>
>    No it is not. For example if I have
> usr/lib/something/libsomething.a, I cannot purge libsomething.a unless
> I explicitly say `*.a` (which could erase even other files in other
> folders), or `usr/lib/*/*.a`, which forces me to know that I have
> folders. (Thus eliminating the generality of makepkg.conf.)
>
>    But again, it doesn't work, as explained above, because
> usr/lib/*/*.a should already exist at source time in order to work.
>
>
>>>        * if a pattern ends with '/' then we use `rm -Rf`, else we use `rm
>>> -f`
>>
>> Instead of ending in /, end it in /* and combine with !emptydirs?
>
>    Again it doesn't work. If a folder contain subfolders it shall
> eliminate only the files in the parent, but not files in children.
>
>    Also emptyfolders is a packaging option, and purging should be
> able to remove a folder completely without leanig on the emptyfolders
> support. (For example there could be cases where a package should
> contain an empty folder.)
>
>
>>>        * maybe if a pattern starts with '@' then it is a regular
>>> expression, etc. (this I have not implemented);
>>>
>>>    Any comments?
>>
>> This all sounds overcomplicated.  Before considering this further, I would
>> like to see an example that can not be handled by the current setup.
>>
>> Allan
>
>    I hope that my examples are enough to show that there is a
> imitation in current *_DIRS and PURGE_TARGETS.
>
>    If I'm wrong about the conf file sourcing please correct me, but
> from what I've seen I think I'm right.
>
>    Thanks,
>    Ciprian.


    One quick note. I've tried what you've suggested (`package/*/...`)
and it doesn't work (as expected `*` expands before anything is in the
current dir).

    Ciprian.