[arch-dev-public] Killing the 'codecs' package
We went over this before - codecs is a useless package, and the licensing is broken. We have opensource alternatives that play just about every format except a few outliers (real media). I'm rebuilding xine-lib right now with codecs removed. Apparently it's an optional dep anyway, as I've been running xine fine without it for some time. mplayer-svn is the last package that depends on the non-free and useless codecs package, so if we can get that rebuilt, we're gold. Now the real question: what do we do with this package. I'm sure it's useful to some people. Should we stick it in unsupported with a warning that no TUs should adopt it? Should we remove it altogether? Opinions?
Now the real question: what do we do with this package. I'm sure it's useful to some people. Should we stick it in unsupported with a warning that no TUs should adopt it? Should we remove it altogether? Opinions?
I think putting it in unsupported would be fine. If some people (end users) decide they really must have it, then more power to them to maintain it in the aur (with a note to not have it taken into community). At that point it would just be a pkgbuild anyway.
On 12/18/07, eliott <eliott@cactuswax.net> wrote:
I think putting it in unsupported would be fine. If some people (end users) decide they really must have it, then more power to them to maintain it in the aur (with a note to not have it taken into community). At that point it would just be a pkgbuild anyway.
Somehow, this doesn't seem very future proof. When a new codec arrives,
it will take some time for VLC/ffmpeg/xine guys to come out with the open source equivalent (for example, the amount of time it took to get .rmvb support) after all the reverse engineering and voodoo magic they do. What if this new codec becomes really popular, really fast? Somehow, it doesn't seem practical to direct users to AUR to get the codecs. I propose instead renaming 'codecs' to 'codecs-nonfree' or something similar, and shipped along with the post_install or post_upgrade message we had discussed earlier. Thanks, Varun
On Tue, Dec 18, 2007 at 06:42:41AM +0530, Varun Acharya wrote:
On 12/18/07, eliott <eliott@cactuswax.net> wrote:
I think putting it in unsupported would be fine. If some people (end users) decide they really must have it, then more power to them to maintain it in the aur (with a note to not have it taken into community). At that point it would just be a pkgbuild anyway.
Somehow, this doesn't seem very future proof. When a new codec arrives, it will take some time for VLC/ffmpeg/xine guys to come out with the open source equivalent (for example, the amount of time it took to get .rmvb support) after all the reverse engineering and voodoo magic they do. What if this new codec becomes really popular, really fast? Somehow, it doesn't seem practical to direct users to AUR to get the codecs. I propose instead renaming 'codecs' to 'codecs-nonfree' or something similar, and shipped along with the post_install or post_upgrade message we had discussed earlier.
Thanks,
Varun
(Please don't make your first line part of the last response) I disagree that this is a problem. When we hit this situation, we can talk about changing it. Jason
On Dec 17, 2007 7:27 PM, Jason Chu <jason@archlinux.org> wrote:
On Tue, Dec 18, 2007 at 06:42:41AM +0530, Varun Acharya wrote:
On 12/18/07, eliott <eliott@cactuswax.net> wrote:
I think putting it in unsupported would be fine. If some people (end users) decide they really must have it, then more power to them to maintain it in the aur (with a note to not have it taken into community). At that point it would just be a pkgbuild anyway.
Somehow, this doesn't seem very future proof. When a new codec arrives, it will take some time for VLC/ffmpeg/xine guys to come out with the open source equivalent (for example, the amount of time it took to get .rmvb support) after all the reverse engineering and voodoo magic they do. What if this new codec becomes really popular, really fast? Somehow, it doesn't seem practical to direct users to AUR to get the codecs. I propose instead renaming 'codecs' to 'codecs-nonfree' or something similar, and shipped along with the post_install or post_upgrade message we had discussed earlier.
Thanks,
Varun
(Please don't make your first line part of the last response)
I disagree that this is a problem. When we hit this situation, we can talk about changing it.
I have to side with Jason here. The "look how long it took last time" defense is a bit silly to me. It's a crappy package which isn't even JUST licensed non-free, some of it is questionably LEGAL at all. For instance, the wm*.dll codecs in there have odd redistribution rules, and IIRC correctly, you need to fill out one of these: http://www.microsoft.com/windows/windowsmedia/licensing/agreements.aspx to redistribute these in binary format. It'd also be worthwhile to take a peek at the quicktime redistribution rules. If you ask me, the hoops we'd have to jump through here to be technically legal are far worse than Ion3, and there seemed to be no contest to killing that off
On Dec 17, 2007 7:44 PM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
On Dec 17, 2007 7:27 PM, Jason Chu <jason@archlinux.org> wrote:
On Tue, Dec 18, 2007 at 06:42:41AM +0530, Varun Acharya wrote:
On 12/18/07, eliott <eliott@cactuswax.net> wrote:
I think putting it in unsupported would be fine. If some people (end users) decide they really must have it, then more power to them to maintain it in the aur (with a note to not have it taken into community). At that point it would just be a pkgbuild anyway.
Somehow, this doesn't seem very future proof. When a new codec arrives, it will take some time for VLC/ffmpeg/xine guys to come out with the open source equivalent (for example, the amount of time it took to get .rmvb support) after all the reverse engineering and voodoo magic they do. What if this new codec becomes really popular, really fast? Somehow, it doesn't seem practical to direct users to AUR to get the codecs. I propose instead renaming 'codecs' to 'codecs-nonfree' or something similar, and shipped along with the post_install or post_upgrade message we had discussed earlier.
Thanks,
Varun
(Please don't make your first line part of the last response)
I disagree that this is a problem. When we hit this situation, we can talk about changing it.
I have to side with Jason here. The "look how long it took last time" defense is a bit silly to me. It's a crappy package which isn't even JUST licensed non-free, some of it is questionably LEGAL at all.
For instance, the wm*.dll codecs in there have odd redistribution rules, and IIRC correctly, you need to fill out one of these: http://www.microsoft.com/windows/windowsmedia/licensing/agreements.aspx to redistribute these in binary format.
It'd also be worthwhile to take a peek at the quicktime redistribution rules.
If you ask me, the hoops we'd have to jump through here to be technically legal are far worse than Ion3, and there seemed to be no contest to killing that off
+1 -Dan
On Dec 18, 2007 7:14 AM, Aaron Griffin <aaronmgriffin@gmail.com> wrote:
For instance, the wm*.dll codecs in there have odd redistribution rules, and IIRC correctly, you need to fill out one of these: http://www.microsoft.com/windows/windowsmedia/licensing/agreements.aspx to redistribute these in binary format.
This is news to me, and is a good enough reason to banish codecs to unsupported. Anyway I'm evaluating the new xine-lib from testing and I'll let you know how it tests out with a large bunch of movie types
Aaron Griffin schrieb:
We went over this before - codecs is a useless package, and the licensing is broken. We have opensource alternatives that play just about every format except a few outliers (real media).
There are videos in the real world which are not supported by any opensource codec. It is however possible to build mplayer with codecs support even if codecs are not installed (I think this is the default), such that anyone could install the codecs and no rebuild of mplayer is necessary. If this is true for xine-lib as well, then we are all happy.
On Dec 18, 2007 6:52 AM, Thomas Bächler <thomas@archlinux.org> wrote:
Aaron Griffin schrieb:
We went over this before - codecs is a useless package, and the licensing is broken. We have opensource alternatives that play just about every format except a few outliers (real media).
There are videos in the real world which are not supported by any opensource codec.
Right, I understand - what I'm saying though, is that there are other alternatives for these formats, and as a last resort, codecs will still be floating around in PKGBUILD form.
Aaron Griffin wrote:
We went over this before - codecs is a useless package, and the licensing is broken. We have opensource alternatives that play just about every format except a few outliers (real media).
I'm rebuilding xine-lib right now with codecs removed. Apparently it's an optional dep anyway, as I've been running xine fine without it for some time. mplayer-svn is the last package that depends on the non-free and useless codecs package, so if we can get that rebuilt, we're gold.
Now the real question: what do we do with this package. I'm sure it's useful to some people. Should we stick it in unsupported with a warning that no TUs should adopt it? Should we remove it altogether? Opinions?
mplayer-svn 25449-1 no longer depends on codecs, and I've also synced it with extra/mplayer. The package is in testing, as it depends on x264>=20071202-1. I can't do a 64 build because phrak's box doesn't have a testing chroot, so if anyone can oblige, that would be great. T.
On Mon, 2007-12-17 at 14:50 -0600, Aaron Griffin wrote:
We went over this before - codecs is a useless package, and the licensing is broken. We have opensource alternatives that play just about every format except a few outliers (real media).
I'm rebuilding xine-lib right now with codecs removed. Apparently it's an optional dep anyway, as I've been running xine fine without it for some time. mplayer-svn is the last package that depends on the non-free and useless codecs package, so if we can get that rebuilt, we're gold.
Now the real question: what do we do with this package. I'm sure it's useful to some people. Should we stick it in unsupported with a warning that no TUs should adopt it? Should we remove it altogether? Opinions?
There's also gstremer0.10-pitfdll on i686 that uses it. If codecs is removed, that package should be removed too.
participants (8)
-
Aaron Griffin
-
Dan McGee
-
eliott
-
Jan de Groot
-
Jason Chu
-
Thomas Bächler
-
Tom K
-
Varun Acharya