From owner-freebsd-ports@freebsd.org Wed Mar 30 21:28:10 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 01E1BAE3F61 for ; Wed, 30 Mar 2016 21:28:10 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 926E6114C for ; Wed, 30 Mar 2016 21:28:09 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-wm0-x22f.google.com with SMTP id 20so88297421wmh.1 for ; Wed, 30 Mar 2016 14:28:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to; bh=gVhVlMfhbvQEMNYZgEhDwXxS21csIQYoqO+xweOWF8o=; b=obzEcOz2XoqywRdT3XerWV/B9UlPp7hYepk915HGUI7p6KRcb4/sCKLkNLCW5OB1eV 6pkkiMTI479dP1SW9tLkPUrvZdIVYEVBg7mVctZwJYCbStJu7dDBSzoBKAcAA46N42qQ aWocuk2OWox6AAc3+YDo2bKyX5twwdSh22Nef7w/jwXzSxBMZD2XYcoIAJRawDpUkTav 9Xdn6W39fMn84OKG59zgmGfhZiCnbnH7RD9KgUR5DXEdmOW0Huhm9bRi+E7GWjeWADvP B3suABejVKEGq93YLANGddJVE8Mp8VIXOMwmRZDxgUgeIlZqKfHY/yKwr/5EdJldGsku 9lHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to; bh=gVhVlMfhbvQEMNYZgEhDwXxS21csIQYoqO+xweOWF8o=; b=gqfXIXgFcyeuwYMhNpRQ7I5iv8NTgE4dgttZ925N0mp3agkevL02U45ZtsGTICKnkx xxZI+SPxukYEfTjNqyUWzo7cplwX48YMbOAsN4r0sH0UcLQtEeGOOV4ejY2/hm7ROI9y NNqcg7+f7PCOd3BDTk8iS8x135OCISqXHQNcNHZxDQ1x64QdXZwtlGXeTepWErWwMVaB GiLYnYP+UaSAwIRjj5AQ/ccAs6l2XJVwIPcKNJ2mr1PjW59NvuSfY1zvx8Q04/TflJgc LfiGLCFFJcLH0A7IN6KfuvaRMEpKHnaguv4DQIxaGcZFURS2PU+vGwte6i9g7OLJXvWP VMoA== X-Gm-Message-State: AD7BkJLJaYYpyM3um9NNqZAkDwAZS7IYRxbxjJPMmFw7ThWphN5vzrv5QNl+coVEV0LLkLXUuIWLmbOL0YGOOQ== MIME-Version: 1.0 X-Received: by 10.28.214.11 with SMTP id n11mr11883189wmg.31.1459373288225; Wed, 30 Mar 2016 14:28:08 -0700 (PDT) Received: by 10.194.23.104 with HTTP; Wed, 30 Mar 2016 14:28:08 -0700 (PDT) Date: Wed, 30 Mar 2016 23:28:08 +0200 Message-ID: Subject: Multiple ffmpeg versions in ports From: Ben Woods To: FreeBSD ports Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.21 X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2016 21:28:10 -0000 Hello ports people, What do you think about having numerous versions of ffmpeg in ports, similar to lang/python? There seems to be a common problem with ffmpeg being a fast moving project, with backward incompatible API/ABI changes between major versions. This results in regular difficulties building ports which depend on ffmpeg, and often ports bundle their own version of ffmpeg to avoid incorrect API difficulties across different operating systems / distros (e.g. HandBrake, plexhometheater). Bundled libraries should be avoided where possible to ensure we can provide clarity on where security vulnerabilities exist (of which there are a few for ffmpeg). [1] Whilst the ffmpeg team appear to be supporting 2.5.x, 2.6.x, 2.7.x, 2.8.x and 3.0.x, we probably only need to maintain a port where it is required for another port to build correctly. To start with I was thinking we should simply create multimedia/ffmpeg30, move multimedia/ffmpeg to multimedia/ffmpeg28, and create a dummy multimedia/ffmpeg which depends on multimedia/ffmpeg30. Any ports which fail to build against multimedia/ffmpeg30 can instead require multimedia/ffmpeg28, and we could add a comment next to the dependency reminding the port maintainer to move to the later version of ffmpeg once it is supported by the package. This would likely mean we will have a number of versions of ffmpeg in the ports system over time, but I think it is the reality that different packages support different versions of the ffmpeg API/ABI, and it would help keep track of what is vulnerable / outdated rather than hiding it by bundled ffmpeg versions. Thoughts? If the idea is supported, I could prepare a phabricator review of the proposed changes. [1] https://www.freebsd.org/doc/en/books/porters-handbook/bundled-libs.html -- From: Benjamin Woods woodsb02@gmail.com