[MPlayer-dev-eng] fixes for mplayer needed on OpenBSD

[Diego Biurrun]

Björn Sandell writes:
> On Tue, 13 Jul 2004 18:42:06 +0200
> Diego Biurrun <diego at biurrun.de> wrote:
> 
> > Björn Sandell writes:
> > > On Mon, 12 Jul 2004 12:35:50 +0200
> > > 
> > > Yepp, this is a typical OpenBSD tweek. We don't install codecs.conf.
> > 
> > But you may have done so in the past and a stray codecs.conf file may
> > be lying around in $(CONFDIR) and it needs to be renamed since old
> > codecs.conf files are incompatible with newer MPlayer versions and
> > playback will break for several files.  This has caused no end of
> > grief in the past.  Nowadays the codecs.conf data is compiled into the
> > binary, but the file will override it, so keeping it around is a BUG
> > and a bad one.
> 
> No, I'm almost dead certain that we have never installed in in such a way
> that it would'nt be removed if the package was deleted.

But what if you update?  The problem arises when you install a newer
MPlayer version on top of an older one and there is an outdated
codecs.conf file lying around.

> > Do you also not create the $(CONFDIR)?  Why?
> 
> Ports are installed in a "fake-root" and the (basically) tarred to a package.
> $(CONFDIR) (/etc/mplayer) is there, it just not created by that Makefile.
> This might not be needed anymore as $(CONFDIR) is \$(DESTDIR)$_confdir.

It's always good to keep patches as small as possible ;-)

> > > > > --- configure.orig	Mon Apr 26 11:44:06 2004
> > > > > +++ configure	Mon Jul 12 00:51:31 2004
> > > > > @@ -4991,7 +4991,7 @@
> > > > >  
> > > > >  echocheck "iconv"
> > > > > -if test "$_iconv" = auto ; then
> > > > > +if test "$_iconv" != no ; then
> > > > 
> > > > I don't know what purpose this serves, but it's wrong as it
> > > > removes the distinction between yes and auto.
> > > 
> > > Ports tweek again; we gotta keep track of dependencies.
> > 
> > I don't understand how this helps you keep track of dependencies.
> > Maybe you can enlighten me..
> 
> I don't remember the gory details now, but the basic idea with ports is that
> you can build a package any machine and install it on any other (kind of like an rpm)
> so it must not make itself dependant on some random lib just because it's there.
> This mmight also be outdate though...

You can always build with certain options, in this case --disable-iconv.

> > > > > --- loader/Makefile.orig	Thu Jan 29 13:01:26 2004
> > > > > +++ loader/Makefile	Mon Jul 12 00:51:31 2004
> > > > > @@ -32,9 +32,6 @@
> > > > >  
> > > > >  libloader.a:  $(LIB_OBJECTS) stubs.s
> > > > >  	$(CC) -c ./stubs.s -o stubs.o
> > > > > -ifeq ($(TARGET_OS),OpenBSD)
> > > > > -	./loader_objfix.sh
> > > > > -endif
> > > > 
> > > > Hmm, this reverses an old portability patch by Björn Sandell.  If
> > > > it is no longer required in newer versions of OpenBSD then we
> > > > should remove loader_objfix.sh as well.
> > > 
> > > Ports tweek again! :-) MPlayer developers wanted to be backwards
> > > compatile, the ports system is not (by design).
> > 
> > Backwards compatible to what?  Older OpenBSD versions?  Which ones?
> 
> Yepp, 3.3 and backwards.

OK.

> > If I read the thread referenced in the other mail correctly..
> > 
> > http://zebra.fh-weingarten.de/~maxi/html/mplayer-users/2004-01/msg00286.html
> > 
> > .. then it's causing problems.  If that's the case, then we should
> > simply remove it.
> 
> It was causing problems; I submitted a patch:
> 
> http://zebra.fh-weingarten.de/~maxi/html/mplayer-dev-eng/2004-01/msg00047.html

OK, read it.  All of this backwards compatibility magic is pretty
pointless if MPlayer does not run out of the box on OpenBSD anyway.
In that case we should try to apply all necessary patches so that it
does and then remove the backwards compatibility cruft.

Diego