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

Baptiste Coudurier baptiste.coudurier
Tue Jan 26 23:01:34 CET 2010


On 01/26/2010 11:53 AM, M?ns Rullg?rd wrote:
> 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.

Yeah, the user can also rm the file, I suggest that systems removes the 
"rm" binary because the user can break his system, and the system will 
get the blame.

Users using make install expect make uninstall to work. Also, IMHO, the 
application is responsible for cleaning its mess.

>>>>> 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.

The analogy of what you said is more like: I cannot be 100% safe 
outside/driving/drinking/eating meat. Therefore I shall not go 
outside/drive/drink/eat meat.

>>> 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.

Of course there is something you can do: let "make uninstall" as is was 
before for other devs that were using it.

>> "make uninstall" was working before,
>
> No, it wasn't.  It CANNOT work.  Therefor no attempt should be made.

If it wasn't working people would not be using it.

>> 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.

That's what I will do for sure.

-- 
Baptiste COUDURIER
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
FFmpeg maintainer                                  http://www.ffmpeg.org



More information about the ffmpeg-cvslog mailing list