[arch-dev-public] Building mplayer
I have been maintaining mplayer for a while now. Unfortunately, during my absence mplayer had to be rebuilt by someone else. The x86_64 version (built by Eric) is fine, but the i686 (built by someone who doesn't know what the "Packager" option in makepkg.conf is for) version is missing features (bug #9288). The mplayer build system sucks. Seriously, it is the worst idea people have ever had, but the guys who are currently maintaining it are proud of it (I had the pleasure of arguing with one of them about autotools vs. mplayer during a two hour car trip last summer). Here is the thing: In autotools, you can use --enable-FOO to force configure to enable a feature. However, configure still checks if all libraries and headers are present and will add the needed options to gcc, or abort if a check fails. In mplayer, --enable-FOO forces the build system to enable a feature, but also skips all checks and doesn't add any options to the compiler, thus making 'make' fail unless you modify Makefiles by hand. This is not only unintuitive but also completely inconsistent with the way autotools work. The only way to properly enable a feature in mplayer is to put no --enable or --disable flag in and hope that configure's autodetection detects it properly. And of course you have to check if everything went fine after configure finished by reading the output summary. I don't have to tell you that this is very distributior-unfriendly. Since there is no way to force mplayer's configure to abort if something we want is missing, we must have the necessary makedepends listed - which we don't, as they are not easy to determine. The only way to properly build mplayer is to watch everything it does carefully and abort if something is wrong. For a while, a "we need clean build chroots so that our packages are not corrupted" attitude has spread, and this is exactly what broke mplayer (I have no idea which makedepend may be missing though). So please, unless you know exactly what you are doing and have much time to check everything, don't build mplayer!
Tuesday 22 January 2008, Thomas Bächler wrote: | I have been maintaining mplayer for a while now. Unfortunately, | during my absence mplayer had to be rebuilt by someone else. The | x86_64 version (built by Eric) is fine, but the i686 (built by | someone who doesn't know what the "Packager" option in | makepkg.conf is for) version is missing features (bug #9288). | | The mplayer build system sucks. Seriously, it is the worst idea | people have ever had, but the guys who are currently maintaining | it are proud of it (I had the pleasure of arguing with one of them | about autotools vs. mplayer during a two hour car trip last | summer). | | Here is the thing: | In autotools, you can use --enable-FOO to force configure to | enable a feature. However, configure still checks if all libraries | and headers are present and will add the needed options to gcc, or | abort if a check fails. | | In mplayer, --enable-FOO forces the build system to enable a | feature, but also skips all checks and doesn't add any options to | the compiler, thus making 'make' fail unless you modify Makefiles | by hand. This is not only unintuitive but also completely | inconsistent with the way autotools work. The only way to properly | enable a feature in mplayer is to put no --enable or --disable | flag in and hope that configure's autodetection detects it | properly. And of course you have to check if everything went fine | after configure finished by reading the output summary. I don't | have to tell you that this is very distributior-unfriendly. | | Since there is no way to force mplayer's configure to abort if | something we want is missing, we must have the necessary | makedepends listed - which we don't, as they are not easy to | determine. The only way to properly build mplayer is to watch | everything it does carefully and abort if something is wrong. | | For a while, a "we need clean build chroots so that our packages | are not corrupted" attitude has spread, and this is exactly what | broke mplayer (I have no idea which makedepend may be missing | though). | | So please, unless you know exactly what you are doing and have | much time to check everything, don't build mplayer! or any other package you are not familiar with. or please do NOT take any dependencies out just to have a clean list that coresponds to namcap output. amen ;) - D -- .·´¯`·.¸.·´¯`·.¸¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸.·´¯`·.¸¸.·´ ° ° ° ° ° ° ><((((º> ° ° ° ° ° <º)))>< <º)))><
Thomas Bächler wrote:
I have been maintaining mplayer for a while now. Unfortunately, during my absence mplayer had to be rebuilt by someone else. The x86_64 version (built by Eric) is fine, but the i686 (built by someone who doesn't know what the "Packager" option in makepkg.conf is for) version is missing features (bug #9288).
The mplayer build system sucks. Seriously, it is the worst idea people have ever had, but the guys who are currently maintaining it are proud of it (I had the pleasure of arguing with one of them about autotools vs. mplayer during a two hour car trip last summer).
Here is the thing: In autotools, you can use --enable-FOO to force configure to enable a feature. However, configure still checks if all libraries and headers are present and will add the needed options to gcc, or abort if a check fails.
In mplayer, --enable-FOO forces the build system to enable a feature, but also skips all checks and doesn't add any options to the compiler, thus making 'make' fail unless you modify Makefiles by hand. This is not only unintuitive but also completely inconsistent with the way autotools work. The only way to properly enable a feature in mplayer is to put no --enable or --disable flag in and hope that configure's autodetection detects it properly. And of course you have to check if everything went fine after configure finished by reading the output summary. I don't have to tell you that this is very distributior-unfriendly.
Since there is no way to force mplayer's configure to abort if something we want is missing, we must have the necessary makedepends listed - which we don't, as they are not easy to determine. The only way to properly build mplayer is to watch everything it does carefully and abort if something is wrong.
For a while, a "we need clean build chroots so that our packages are not corrupted" attitude has spread, and this is exactly what broke mplayer (I have no idea which makedepend may be missing though).
So please, unless you know exactly what you are doing and have much time to check everything, don't build mplayer!
Just to point out the yin and yang: The x264 upgrade in [testing] broke mplayer, since there was an .so bump. One of the things I did not do as well as I should was to publicize that fact and put up a todo list. I eventually did that, but certainly later than would have been advisable. Once that happened, Jason rebuilt mplayer. It was a good move, it was completely broken in [testing] for a while, and I know his intentions were to get things up and going again for people whose stuff was broken. These packages sat in [testing] for a LONG time. I did that to give us a really rigorous trial period before rolling everything out. I monitored bug reports and was careful to try and figure out the effects of the new rebuilds. I can only assume folks who are having problems now weren't using them then. Then we released the packages to [extra] and now bugs are being found. Aside from more up-front notification about package dependencies, which I am instituting as part of my process from now on, I think the process worked as well as it could here. I'm not sure what else we could do differently except maybe to document in a README in the PKGBUILD directory in CVS any quirks about a package that would cause a chroot build not to work, to drop as breadcrumbs to someone who might find themselves rebuilding a package they don't know much about. Another possibility would be to require a sign-off from the maintainer if a non-maintainer builds the package, before rolling out to [extra] or [core]. This would guarantee that the package had the blessing of the person who knows the most about the package before it actually goes to the main repos. Anyone have any other ideas of how we could have navigated this better? - P P.S. Feeling your pain about the mplayer build system! Building eclipse is the largest nightmare I've had to deal with, and it's pretty bad, too.
That was me, sorry. On Tue, Jan 22, 2008 at 06:05:55PM +0100, Thomas Bächler wrote:
I have been maintaining mplayer for a while now. Unfortunately, during my absence mplayer had to be rebuilt by someone else. The x86_64 version (built by Eric) is fine, but the i686 (built by someone who doesn't know what the "Packager" option in makepkg.conf is for) version is missing features (bug #9288).
The Packager option wasn't enabled because I was building in a chroot ;)
The mplayer build system sucks. Seriously, it is the worst idea people have ever had, but the guys who are currently maintaining it are proud of it (I had the pleasure of arguing with one of them about autotools vs. mplayer during a two hour car trip last summer).
Here is the thing: In autotools, you can use --enable-FOO to force configure to enable a feature. However, configure still checks if all libraries and headers are present and will add the needed options to gcc, or abort if a check fails.
In mplayer, --enable-FOO forces the build system to enable a feature, but also skips all checks and doesn't add any options to the compiler, thus making 'make' fail unless you modify Makefiles by hand. This is not only unintuitive but also completely inconsistent with the way autotools work. The only way to properly enable a feature in mplayer is to put no --enable or --disable flag in and hope that configure's autodetection detects it properly. And of course you have to check if everything went fine after configure finished by reading the output summary. I don't have to tell you that this is very distributior-unfriendly.
Eww.
Since there is no way to force mplayer's configure to abort if something we want is missing, we must have the necessary makedepends listed - which we don't, as they are not easy to determine. The only way to properly build mplayer is to watch everything it does carefully and abort if something is wrong.
For a while, a "we need clean build chroots so that our packages are not corrupted" attitude has spread, and this is exactly what broke mplayer (I have no idea which makedepend may be missing though).
I hope you didn't say that in a derisive sort of way. I still think building in chroots is an excellent idea. I'm really not trying to be defensive or passive aggressive, but wouldn't it be great if mplayer did have all the makedepends listed properly? Then we could rebuild it in a chroot *and* have all of the features enabled.
So please, unless you know exactly what you are doing and have much time to check everything, don't build mplayer!
I'm very sorry about rebuilding this thing. Here's my documentation surrounding it: http://bugs.archlinux.org/task/8864 http://archlinux.org/pipermail/arch-dev-public/2007-December/003627.html So, next time I won't update mplayer. I'll just be part of the crowd shouting "Rabble rabble rabble rabble". Jason
Jason Chu schrieb:
The Packager option wasn't enabled because I was building in a chroot ;)
Should be fixed, the chroots must not break the Packager field in the package.
For a while, a "we need clean build chroots so that our packages are not corrupted" attitude has spread, and this is exactly what broke mplayer (I have no idea which makedepend may be missing though).
I hope you didn't say that in a derisive sort of way. I still think building in chroots is an excellent idea.
Maybe they are, but I was always able to build clean packages without them.
I'm really not trying to be defensive or passive aggressive, but wouldn't it be great if mplayer did have all the makedepends listed properly? Then we could rebuild it in a chroot *and* have all of the features enabled.
It would be great, and I added mesa to makedepends, I hope that will fix this specific problem in the future. However, I still cannot guarantee that it will build properly inside a chroot.
So, next time I won't update mplayer. I'll just be part of the crowd shouting "Rabble rabble rabble rabble".
An even worse idea, I'm glad someone took care of it, as I was terribly unavailable at the time. The post is primarily for documentation, I will add a link to it in the mplayer PKGBUILD and document what must be checked when building it.
participants (4)
-
Damir Perisa
-
Jason Chu
-
Paul Mattal
-
Thomas Bächler