[FFmpeg-devel] [PATCH 2/3] configure: Do not create/install versioned DLLs on OS/2.

[Dmitriy Kuminov]

On 2016-04-20 11:48:33 +0000, KO Myung-Hun said:

> No, it's not because ln_s overriding is already there. And there is just
> no need to replace it.

Wrong. "There is no need" sounds like if it were the truth but in fact 
it's not, it's just your opinion.

> Did you present any real-life cases where not using symlinks in FFmpeg
> development hurts ?

Yes, I did. In detail. Please read my previous message closer.

> However, Dave reported some failure cases due to removing ln_s
> overriding.

Where did he do that? I didn't see it. He only mentioned that he often 
gets less failures in his old environment than in the new one (by the 
new one he refers to RPM/YUM with gcc 4.9.2 I suppose). But this 
doesn't even mean that ln is involved here. Nor does it mean that ln 
shouldn't be used per se if some tests fail (it would mean, however, 
that I'd have to fix tests before asking for my patch to be accepted. 
And if anybody gives me any evidence that FATE tests fail because of 
*my* patch, I will fix it — when I have some spare time.)

>  BTW, maybe aren't you thinking that FATE is not a part of
> FFmpeg development ?

It of course is. See above.

> Because it just does just what is already doing well, without any
> benefits.

Not true. I named you the benefits. And you still can't give me at 
least one real problem of using ln instead of cp.

>  In addition, I suggested that you check if ln -s works really
> before overriding ln_s, however you did not. I don't have to do it
> because FFmpeg already works well even if without it.

I asked you to do so because it's you who needs this in the first place 
and who can test it in the environment that does not support symlinks. 
My environment supports them so it's rather problematic to check. And 
also this is what I call collaboration. BTW, when I work with your 
patches to the projects that I maintain as a committer, I discuss it 
with you and if you refuse to modify something in your patch because 
you don't care, I simply do it myself and I give you credit for your 
work. I expect something similar from you at least.

> I don't understand what you are saying. You disabled those DLL creations
> in this patch, didn't you ?

If you checked my patch and makefiles closer before arguing you would 
understand me. There are two places where versioned DLLs are created: 
the library build stage and the install stage. For the install stage it 
was enough to remove a couple of variables. But the build stage always 
first links avcodeXX.dll and then calls ln_s on it to create 
avcodec.dll (via a separate target), this can't be altered via 
variables. If you use cp, you will get a dumb and broken library that 
will also be lxlite'd. If you use ln, the library will also be broken 
but it will at least not occupy any disk space and will not be lxlite'd.

> There is nobody who is less busy than you, here. If you don't modify
> this patch yourself, nobody will do that. And who cares about divergent
> downstream ?

I do care about consistency, collaboration and prevention of artificial 
entropy growth. But if I'm the only one who cares, I assure you I feel 
perfectly fine maintaining our own BWW repositories and I also don't 
need my name to be listed in the maintainers file or among commiters. 
It's you who's sabotaging my work here without any particular reason 
besides your religious belief that symlinks is evil. And it's quite 
natural that in this situation I don't have any further wish to change 
my patch just to make your internal believer happy. What about "ups" 
and "downs", well, it's just a matter of viewport, please don't be so 
childish here.


A question to maintainers with commit rights: please clarify, what 
should I do to have my patches applied?


-- 
Kind regards,
Dmitriy Kuminov
CPO of bww bitwise works GmbH