Hi, > Making a binary mplayer package is very difficult and the result can't be > perfect for everybody because you have to make choices about what will be > enabled in it (and add deps) and what will not (but some users might want > it). It's the prototype of the package that should stay source-based if > possible. Well my main issue wasn't so much about an up-to-date, "bloated" or modified mplayer package but a bump of the x264 package wich is like half a year old if I interpret the versioning scheme right. I just wanted to show that there are some showstoppers in the way if we want to provide an up to date x264. I'm perfectly fine with the mplayer version from the repos but I don't think that the PKGBUILD can be reused for the latest available mplayer sources if it is configured with x264 support (as it is the case now) because of the rewrite in the mplayer/ffmpeg code. So I'm not asking for new features and stuff but if future mplayer packages should be built against an updated x264 package and provide the same functionality as todays version, the configure flags might need to be adapted as pointed out by the forums thread. I'm sure that Hugo makes the right coices and would be able to find (better) solution for this on his own, but nevertheless giving the forum thread and my mail a read could perhaps save a bit of time ;) If there is a possibility to "recycle" the now used PKGBUILD I definitely won't complain about it. Greets, Markus
