On date Wednesday 2011-05-25 10:35:05 -0700, Alex Converse encoded:
> 2011/5/25 Måns Rullgård <[email protected]>:
> > Diego Biurrun <[email protected]> writes:
> >
> >> ---
> >>  Makefile   |    2 ++
> >>  subdir.mak |    6 ++++--
> >>  2 files changed, 6 insertions(+), 2 deletions(-)
> >>
> >> This is an RFC patch that addresses some oversights in the 'uninstall'
> >> target.  I implemented it to remove absolutely everything that the
> >> 'install' target may have dropped onto the filesystem.  This may or may
> >> not be considered overzealous.
> >>
> >> Removing BUILT_HEADERS and INCINSTDIR I consider absolutely safe and
> >> essential.  Removing BINDIR, LIBDIR/pkgconfig and MANDIR/man1 may be
> >> discussed, but since it will only remove the directories if they are
> >> empty anyway there should be no negative sideeffects.
> >
> > make uninstall is a stupid idea from the start.  If you want to mix
> > stuff from multiple sources in the same prefix, use a proper package
> > manager, not something half-baked in a makefile that can never do quite
> > the right thing.

> >
> > No amount of "but autohell does it" will convince me uninstall is a good
> > idea.  We should remove it once and for all.  In fact we already did
> > that once, but some loud troll had it reinstated.  That troll is gone
> > now, so there's no reason to keep this ridiculous thing around anymore.

It was re-added per user requests, and users are used to expect to
find it (make install... damn wrong install path... make uninstall -
that's better than a manual uninstall).

I tried stow some time ago but that was brittle and underkill, the
safe alternative if you lack a package manager is an opt/-like install.

A compromise would be to warn users that the uninstall operation is
intrinsically unsafe and thus its use is deprecated/discouraged,
adding a warning even in the case you remove it would be a good idea,
anyway that's your choice.
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to