[MPlayer-dev-eng] deterministic builds

[D Richard Felker III]

On Tue, Dec 23, 2003 at 12:54:52PM +0000, Adam Rice wrote:
> Good answer. Ok, what about DVD menus? Everyone was sitting pretty with their
> hands over their ears pretending that DVD menus didn't exist, then Ogle came
> along. Man that thing was an ugly hack, it was amazing it worked at all, but
> within weeks the inertia was broken and Xine had DVD menu support. Of course,
> MPlayer is still pretending that DVD menus don't exist... ;-)

No, we've made it very clear. There are two problems:

1. MPlayer (G1)'s architecture does not like DVD menus. This probably
   won't change.
2. The software (libdvdnav) does not provide a sufficiently general
   api to support the way MPlayer wants to handle input streams.

Problem 1 will go away easily with G2. Problem 2 is more of a pain and
will require hacks or else a fork/rewrite of libdvdnav. The MPlayer
developers are not interested in writing this stuff because we find it
useless and unrewarding. Decoding Sorensen is exciting. Displaying
menus isn't...

> And you're also not acknowledging what you've given up in exchange for your
> expertise. How much longer is G2 taking to develop than G1? Why do you think
> that is? Expertise always brings with it a certain inflexibility, that in the
> end can be more crippling than ignorance. Will G2 ever be finished?

Yes. Right now I'm the one holding things up, because the new video
layer isn't complete and it's key to everything else...

> > This is the first example of "Microsoft-esque". See below for another.
> 
> I see your point, but to me it doesn't really qualify as Microsoft-esque
> unless it hides bugs or is actively user-hostile.

It does both! For example, if the software installs files somewhere it
shouldn't, I can't see that it's going to do it, and then it trashes
my system!! IMO installing files in bad places is a _bug_, and keeping
the user from seeing this with "make -n install" is "user-hostile".
Typing "make -n install" should always output a _very_ small number of
user-readable commands so the user can evaluate what will happen
before doing it!

> >                                   Also, certain files will get
> > recompiled at "make install" time, which means compiling as root (very
> > bad!) and thus root-owned files in your user's source dirs!
> 
> I'll admit, I had wondered about that, but never took the time to investigate
> properly.

Also, this .libs behavior is "user-hostile". It makes it nearly
impossible to install "by hand" if you don't like what "make install"
is going to do (and if you can somehow miraculously figure out what
it's going to do before it does it...). Also it makes it difficult to
install just one binary from a package that contains lots of other
useless programs the user doesn't want installed.

> > Granted libtool and automake are not the same, but they're so
> > incestuously intertwined they might as well be...
> 
> Everyone I've ever heard express a preference loaths libtool. The same is not
> true of automake.

Here's a good related read:
http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html

> > Every change to MPlayer's configure script is reviewed by each
> > developer as it's committed to cvs. On the other hand, if you update
> > configure.ac and generate configure from it, the configure.ac commit
> > will be human-readable (and will be reviewed), but the configure
> > commit might as well be a binary file! No one will review it, because
> > it's so horribly unreadable, so any contributor with cvs access could
> > put trojan code in it!
> 
> I had wondered why most CVS repositories are missing the configure file,
> requiring CVS users to run automake themselves. Thanks for clearing that up
> for me.

IMO most of them aren't clueful enough about security to be doing it
for security reasons. It's just that every time you commit a new
configure (made with autosh*t utils), it pollutes the CVS repository
with thousands of lines of patches, because autoconf _hard-codes_ line
numbers into the script for error reporting/logging! This makes your
repository grow very quickly, and spams everyone's mailboxes with
cvslog...

Rich