Re: [Bug-zile] Running bleeding-edge github Zile [WAS Re: Problems generating manpage]

[Gary V. Vaughan]

Hi Sftefan,

> On 01 Aug 2014, at 21:05, Stefan Husmann <address@hidden> wrote:
> 
>> Am 01.08.2014 um 22:01 schrieb Stefan Husmann:
>>> Am 30.07.2014 um 22:33 schrieb Gary V. Vaughan:
>>> Hi Stefan,
>>> 
>>>> On Jul 30, 2014, at 7:51 PM, Stefan Husmann <address@hidden> wrote:
>>>> 
>>>> thanks again, I followed your advices:
>>>> 
>>>> Am 30.07.2014 um 16:12 schrieb Gary V. Vaughan:
>> 
>>>>>   - ncurses is not a Zile requirement, but it is missing from Arch's 
>>>>> lua-posix package dependencies;
>>>> I could file a bug report for lua-posix (official package), but would need 
>>>> some evidence for this statement
>>> 
>>> Yes, please do (I'm also the maintainer of luaposix upstream).
>> done, see https://bugs.archlinux.org/task/41437
> They already replied, ncurses is in the dependency chain. lua-posix -> lua -> 
> readline -> ncurses.
> 
> Is that okay for you?

Thanks for following up on that :-)

I'm not sure what the policy for dependency relationships in Arch packages is, 
but compared to my day job (where I package Free Software for vendor Unices) it 
seems like an error prone way to do it from my perspective. For instance, what 
if someone wants a pure MIT licensed build of Lua for a non-GPL compatible 
project, or a non-cli version of Lua for running embedded scripts, or uses a 
readline built with termcap instead of curses etc etc? Any of those builds a 
Lua package that does not indirectly depend on curses any more, even though 
luaposix itself still needs a curses library to work.  More sensible IMHO is to 
always list all direct dependencies in every package, because then removing a 
dependency somewhere else in the package dependency graph absolutely cannot 
cause unexpected breakage in other indirectly connected nodes.

Of course, if Arch policy already mandates or provides tools for exploring the 
dependency graph to reattach removed dependencies in subsequent package 
versions, or similar, it's certainly not my place to complain.

Cheers,
-- 
Gary V. Vaughan (gary AT vaughan DOT pe)