[FFmpeg-cvslog] r21226 - in trunk: Makefile common.mak subdir.mak

Måns Rullgård mans
Tue Jan 26 20:53:23 CET 2010


Baptiste Coudurier <baptiste.coudurier at gmail.com> writes:

> On 01/26/2010 10:06 AM, M?ns Rullg?rd wrote:
>> Ramiro Polla<ramiro.polla at gmail.com>  writes:
>>
>>> 2010/1/26 M?ns Rullg?rd<mans at mansr.com>:
>>>> Michael Niedermayer<michaelni at gmx.at>  writes:
>>>>> On Mon, Jan 25, 2010 at 03:17:53AM +0000, M?ns Rullg?rd wrote:
>>>>>> Baptiste Coudurier<baptiste.coudurier at gmail.com>  writes:
>>>>>>> On 1/15/10 11:26 AM, Reimar D?ffinger wrote:
>>>>>>>> On Fri, Jan 15, 2010 at 08:16:28PM +0100, ramiro wrote:
>>>>>>>>> Author: ramiro
>>>>>>>>> Date: Fri Jan 15 20:16:28 2010
>>>>>>>>> New Revision: 21226
>>>>>>>>>
>>>>>>>>> Log:
>>>>>>>>> Get one step closer to world domination.
>>>>>>>>> Remove "make uninstall".
>>>>>>>>
>>>>>>>> I'm all for a joke, but how about at least printing something
>>>>>>>> useful in addition (if you really want after a sleep 1) like
>>>>>>>> "Actually this way of uninstalling is just too unreliable, consider
>>>>>>>> using a tool like (whatever Mans mentioned) and look in .... for
>>>>>>>> files to manually remove").
>>>>>>>
>>>>>>> Well, I'm all for a joke as well. However I do use make uninstall and
>>>>>>> I know why I'm using it. For example I want to remove the .a from a
>>>>>>> static compilation because I want to test shared libs, or vice versa.
>>>>>>
>>>>>> That sounds like using the wrong tool for the job.  If you don't want
>>>>>> static libs, use --disable-static.  I don't even see how uninstall
>>>>>> could possibly be of relevance to what you seem to be describing.
>>>>> [...]
>>>>>>> Printing the message is fine with me, but keep the uninstall working.
>>>>>>> Thanks for your understanding.
>>>>>>
>>>>>> Keeping it working takes effort.  I will not waste my time on
>>>>>> something that already has superior solutions.
>>>>>
>>>>> I also think the uninstall target was usefull to some users.
>>>>
>>>> It was dangerous.
>>>
>>> So is make install, it might overwrite your previous installs, or not
>>> install enough (I remember we missed some .h files a while ago)...
>>> Should we remove that as well?
>>
>> Please stop being ridiculous.  Everybody know you're supposed to
>> install into an empty directory and use the system tools to transfer
>> the files into the live filesystem.
>
> IMHO you are the one being ridiculous here. WTF are you talking about.
> Ramiro's point is perfectly valid here.

If we forget to install a header file, WE can fix that (and do).  If
the user does PERFECTLY NORMAL things that cause "make uninstall" to
break his system, there is NOTHING we can about that, yet we still get
the blame.

>>>> Whatever people may have used if for,
>>>
>>> To uninstall.
>>
>> And it didn't always work.  Furthermore, it CANNOT be made to always
>> work correctly.
>
> That's not a reason for removing something that worked 99%.

If I stand on the tracks when the train is coming, there's a 99%
chance I'll manage to jump off in time.  That doesn't make it a good
idea.

>> System package management should not be left to makefiles of each and
>> every piece of software.  Deal with it.
>
> No, if the people you work with, for fun or something else would like
> to have a feature they find useful, you should at least respect their
> wish and do what is possible to help.

I'm doing exactly that.  In this case, there is nothing I can do to
help.  What they are asking for is outside the scope for FFmpeg.

> "make uninstall" was working before,

No, it wasn't.  It CANNOT work.  Therefor no attempt should be made.

> nobody proposed to remove it except you so far. Please revert the
> commit.

I was not the one who removed it, I merely approved a patch.  Feel
free to revert it in your fork.

-- 
M?ns Rullg?rd
mans at mansr.com



More information about the ffmpeg-cvslog mailing list