Arch (mplayer) depending on non-Free software? Why? :-(

codergeek42 · 2005-07-14 19:03:51

I didn't notice this at first, but when I went to update my Arch system earlier yesterday, updating mplayer using pacman tells me that it also needs to update a few things (namely codecs and divx4linux) which are non-Free. I've attempted to add them to IgnorePkg in my pacman configuration but to no avail. I'm well aware that I can edit the file and remove these from the dependency list, but why are they dependencies in the first place? :x One reason I wanted to try Arch in the first place was fast and easy package management (I'm getting slightly impatient with compile times in Gentoo on my older system) but I can't stay with Arch if it continues to encourage the use of proprietary software packages like this.

Perhaps the maintainer (dorphell according to the package file) could remove these two dependencies? I know they help immensly with compatibility but I believe they should remain separate packages, optional for the user to install.

kth5 · 2005-07-14 19:16:37

i really do doubt that many users will approve of this like you do. removing codecs is limiting the amount of playableformats significantly. besides, one fredom is choice. so if you do not agree with using proprietory software many people around here will chose to object i bet.

i wouldn't mind having codecs not as a hard dependency for xine-libs and mplayer though. they should instead spit out a notification that there's a package called codec which... blah blah

paranoos · 2005-07-14 19:17:55

we've had this discussion before ...

some distros are philosophical and don't like including non-free packages (debian), or don't include any at all (extremadura afaik). if you ask me, arch is pragmatic, and provides what is most convenient. i rely on mplayer to play wma and quicktime mov for me, since a lot of content online is encoded this way.

ignorepkg is used to prevent a package from being updated ... installing a package that depends on an ignored pkg will result in pacman asking if you want to install it anyway. however, if you don't want codecs installed, you could get pacman to force remove that package, without getting rid of mplayer as well. i don't see a way for preventing pacman from installing codecs without making dummy packages. (EDIT: phrakture explains how below )

EDIT: doing what kth5 suggests seems like a good idea, however namcap wouldn't like it, so i don't think it's the right way to do it.

codergeek42 · 2005-07-14 19:18:35

Yeah. I have no problems with Arch having those in its repos, but I really think it would be more appropriate as separate and optional packaging.

codergeek42 · 2005-07-14 19:19:26

Err I can't believe I didn't see that thread. *smacks himself*

phrakture · 2005-07-14 19:19:30

codergeek42 wrote:

Perhaps the maintainer (dorphell according to the package file) could remove these two dependencies? I know they help immensly with compatibility but I believe they should remain separate packages, optional for the user to install.

And you obviously know better than dorphell?

This issue has been discussed to death - the main point is that no one cares... "free software" is all about the right to choose what you use and what you don't use... people bitching "arch shouldn't include non-free packages" is limiting that choice... if you don't want the codecs, don't use them

pacman -Sd mplayer

iBertus · 2005-07-14 19:23:16

ehh.. wow! I get the feeling that most Arch users don't worry about stuff like that - most use Arch because it works well, not because of some ideological stance.

With that said, I tried to install just mplayer without divx and faad but it won't run. The package was built to need those deps and so you'll have to rebuild it to use them without.

Dusty · 2005-07-14 19:24:04

there's also the option of building your own package too. 8-)

Dusty

codergeek42 · 2005-07-14 19:34:26

Good point, Dusty.

I'll be an even happier Arch user once the License fields thing is implemented.

*goes off to download mplayer source tarball*

phrakture · 2005-07-14 19:43:30

codergeek42 wrote:

*goes off to download mplayer source tarball*

makepkg?

sarah31 · 2005-07-14 19:46:46

You could repackage the codecs and mplayer package to exclude non-free codecs. Keep in mind you will kick yourself for it though it will remove alot of playablility for mplayer. Howeverr, if your wish is to eliminate non-free dependencies than best you repackage what you need to (rebuild java support out of the java packages, etc.).

dorphell would rather face the few extremists than submit a virtually nonfunctional player. arch gives you the option to easily rebuild a package the way you want should you desire so, so it is not like you are being FORCED into anything.

LB06 · 2005-07-15 11:25:36

It is impossible to accomodate every single user, if packages are distributed in binary form (ok, apart from plugins).

For example, before the latest alsa upgrade I couldn't get multiple audio streams to work without a sound server. Since I'm a KDE user, the sound server I am referring to is artsd, of course. So I had to rebuild mplayer and xine-lib, in order to get support for arts. And who gives a shit? That is exactly what ABS is for.

Same story in your case. Change the PKGBUILD to suit your needs and recompile the package. Btw, it's not a good idea to do ./configure && make manually, because pacman won't know it exists. It'll soon become very chaotic.

JGC · 2005-07-15 16:47:59

I agree that divx4linux should go though. The package doesn't work anymore, but it is still linked into mplayer, while mplayer will never touch the codecs, because it can't use the functions of it (in fact, it utilizes ffmpeg to display divx)

paranoos · 2005-07-15 18:12:23

according to mplayer documentation, divx4linux is needed to decode divx 3.x or older files. keep it for compatibility's sake -- which is why it's there.

Gullible Jones · 2005-07-15 19:06:01

JGC wrote:

I agree that divx4linux should go though. The package doesn't work anymore, but it is still linked into mplayer, while mplayer will never touch the codecs, because it can't use the functions of it (in fact, it utilizes ffmpeg to display divx)

I've used MPlayer to play divx files without ffmpeg on my system. Does MPlayer have ffmpeg built into it or something?

And what about Xine? What does that use to play divx?

JGC · 2005-07-15 20:22:53

xvidcore can play most divx stuff also. Furthermore, you have the win32 dlls that take a big part of the codecs for them.

The libraries supplied with divx4linux are compiled with a compiler that produces libraries which are incompatible with gcc 3.3 and up. Though divx4linux is completely broken, the package is still in. Closed source software is bad, you are completely dependant on the vendor of the piece of software. If they don't compile their piece of garbage with a decent compiler, then you just can't use it.

sarah31 · 2005-07-15 22:47:44

JGC wrote:

Closed source software is bad, you are completely dependant on the vendor of the piece of software. If they don't compile their piece of garbage with a decent compiler, then you just can't use it.

Sigh. The only "bad" closed source software is the software that doesn't do what it is supposed to or is not maintained well. I have use LOTS of closed source software that is superior in everyway to it's open source "equivalent". I also own close source software that was inexpensive and all ensuing upgrades are free. All of that software has saved me hundreds of dollars, alot of time and so forth.

Face it there is crap open source and crap closed source software everywhere. To me no matter what the license is it all depends on how well the development team is and how they listen to their customers is what is most important and to be honest I have gotten extremely excellent service from just as many closed source developers as I have open source.

You also fail to realize that non-free applications play a huge role in open source.

Gullible Jones · 2005-07-15 23:27:27

Well, to be fair, crap open-source software is better than crap proprietary software: you can at least see what made it the crap that it is.

Mind, that isn't a very big advantage... :oops:

archdaemon · 2005-07-16 01:45:54

I have two principles when it comes to dependencies. 1: Less is more. 2: I don't care about ideological purity. Mplayer has 67 deps and they should be cut down but only on the principle of usefulness; not purity. But I think the mplayer guys are right to get pissed off at all the distros shipping horribly broken useless mplayers and causing people to think mplayer is no good or giving them the headaches of dealing with the complaints.

Somebody hit on this: if ideological purity is a primary criterion, Debian is there. People come to your Arches and Slackwares and whatnot in part because that's probably not as big a deal to them.

But this is a good time to be somewhat off-topic and yell about Knome deps. If a package can possibly be built without them, it should be. I notice a *lot* of excessive Gnome-isms in Arch packaging.

Anyway, just my two cents - I'll shut up now. It's just that, while I love OSS, I can't stand GNUlitical Correctness.

iBertus · 2005-07-16 03:25:51

I use and will continue to use what works best for the job. If it's closed-source then it's closed-source. I have been lucky and found that most of the best software is F/OSS. We all must accept that some media formats are protected IP of some large company and that closed-source codecs are the best we can do.

JGC · 2005-07-16 16:18:20

Problem with divx4linux is that it is broken when using gcc 3.3 and higher and that it is non-free, so you can't fix it yourself. Mplayer links to divx4linux libraries, but can't use it at all. It uses the win32 dlls or xvidcore or whatever other app to do its job.

Gullible Jones · 2005-07-16 18:09:44

Well, if divx4linux is broken, it ought to be gotten rid of. Just like fluxbox "stable" version.

iphitus · 2005-07-17 02:36:18

Gullible Jones wrote:

Well, if divx4linux is broken, it ought to be gotten rid of. Just like fluxbox "stable" version.

You know though, some people do watch divx movies, it's an extremely common format. And its not like theres a working alternative like there is with fluxbox stable. Sure YOU might use GCC4. But I dont

archdaemon, 67 deps?

depends=('x-server' 'libmad' 'libungif' 'libvorbis' 'divx4linux' 'cdparanoia' 
         'gtk' 'codecs' 'sdl' 'libjpeg' 'lame' 'libtheora' 'esd' 'faad2')

doesnt look like 67 to me. Unless you've got a clean install without X or anything else whatsoever, then some of these would have other deps as well.

iphitus

Arch Linux

#1 2005-07-14 19:03:51

Arch (mplayer) depending on non-Free software? Why? :-(

#2 2005-07-14 19:16:37

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#3 2005-07-14 19:17:55

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#4 2005-07-14 19:18:35

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#5 2005-07-14 19:19:26

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#6 2005-07-14 19:19:30

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#7 2005-07-14 19:23:16

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#8 2005-07-14 19:24:04

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#9 2005-07-14 19:34:26

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#10 2005-07-14 19:43:30

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#11 2005-07-14 19:46:46

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#12 2005-07-15 11:25:36

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#13 2005-07-15 16:47:59

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#14 2005-07-15 18:12:23

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#15 2005-07-15 19:06:01

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#16 2005-07-15 20:22:53

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#17 2005-07-15 22:47:44

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#18 2005-07-15 23:27:27

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#19 2005-07-16 01:45:54

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#20 2005-07-16 03:25:51

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#21 2005-07-16 16:18:20

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#22 2005-07-16 18:09:44

Re: Arch (mplayer) depending on non-Free software? Why? :-(

#23 2005-07-17 02:36:18

Re: Arch (mplayer) depending on non-Free software? Why? :-(

Board footer