[MPlayer-dev-eng] deterministic builds

[Adam Rice]

Quoting D Richard Felker III (dalias at aerifal.cx):
> Forgive me for being upfront about this, but it doesn't sound like you
> have 1% of the experience needed to make a distribution.

You never have the experience you need until after you need it... that's life.
I would never try to do something like this, because I can think of a hundred
reasons why it wouldn't work. Sometimes it takes someone who doesn't know why
it shouldn't work to try something and find that it does work. Back when
MPlayer was started, it was common knowledge that proprietary codecs couldn't
be reverse engineered.

> Uhg... Automake is the bane of compile-from-source systems! It makes
> software take twice as long to build,

Twice as long compared to what? I've used auto-configure systems that were
faster, but I wouldn't count mplayer's among them. Obviously nothing is as
fast as compiling without configuration, but then, nothing is as slow as
configuring software manually.

>                                       completely obfuscates the
> process so you can't see what's going to get installed where (ever try
> "make -n install" with an automake project?),

Fair comment.

>                                               and uses all sorts of
> microsoft-esque techniques to hide what's going on from the user.

Microsoft-esque? I have to confess I haven't used the latest version of
automake, does it popup an animated gif saying "configuring" and refuse to
tell you what it's doing?

> (This happens to make it exceptionally great for hiding trojans in the
> build system, too.)

As opposed to MPlayer's 6000 line shell script? Hell, anything more
complicated than gcc *.c could hide a trojan, and I'm not even sure I'd trust
that.

>            One way is to ldd the binaries that get built and track
> dependencies that way.

The trouble is repeatability. It's no good if yesterday's MPlayer build
depends on ALSA 1.0 and today's depends on ALSA 0.9. Clever config scripts
are great for users, but horrible for autobuilders. It would probably help if
configure had a standard option
--disable-everything-i-havent-explicitly-enabled!

>                        Another is to build in some sort of
> chroot/sandbox environment where you hide extra libs.

I think this is unavoidable. To get reproducable builds you absolutely have to
have a santised environment. Even then there's trouble with stuff that builds
differently depending on installed kernel version.

> But for mplayer, I don't see why you don't just --disable the libs you
> definitely don't want linked...

And what happens when libcaca support is added in the next release?

> You're not going to make yourself any friends on this list by
> continuing to praise automake.

I think you could have safely left off the second half of that sentence.

Adam

-- 
Adam Rice -- adamrice at ntlworld.com -- Blackburn, Lancashire, England