arch's weakness: dependency resolving

taylorchu · 2011-09-18 18:21:01

youtube video said a weakness about arch: it pulls too much dependencies which we might not need.
I know that some examples shown in the video are fixed, but some still exist.

watch this youtube video: http://www.youtube.com/watch?v=flmX9GYwyiI

I think putting some deps in [optdepends] would solve this. for example, I have seen mplayer grows to be a monster because someone reports he/she wants ... support in mplayer. In this case, would it better to put ... in optdepends?

wonder · 2011-09-18 18:25:44

mplayer is one fat binary who links to everything. you cannot move dependencies to optdepends

.:B:. · 2011-09-18 18:26:33

You can only move stuff to optdepends if making it an optional dependency does not break the binary...

lifeafter2am · 2011-09-18 18:28:56

taylorchu wrote:

youtube video said a weakness about arch: it pulls too much dependencies which we might not need.
I know that some examples shown in the video are fixed, but some still exist.
watch this youtube video: http://www.youtube.com/watch?v=flmX9GYwyiI
I think putting some deps in [optdepends] would solve this. for example, I have seen mplayer grows to be a monster because someone reports he/she wants ... support in mplayer. In this case, would it better to put ... in optdepends?

I recommend you look into the differences between a source-based and a binary-based distribution. Because, as B says, you can't simply move things into [optdepends] if it breaks the dependencies at compile time. This is where things like Gentoo's USE flags come into play.

karol · 2011-09-18 18:35:29

We have AUR, e.g. https://aur.archlinux.org/packages.php?ID=26578

taylorchu · 2011-09-18 18:45:44

@lifeafter2am
if it breaks dependency at compile time, it should surly go to [makedepend].
if it breaks dependency at run time, it should surly go to [depend]

But sometimes official packages enable some flags to have features, which is less "vanilla". "having less flags" or "having flags that result in less depends" is better.

@karol
yup. I know such thing exists. But I am discussing the official packages. I feel that arch official packages should have mininal dependencies, while the packages in aur enable additional flags to have more features. It is funny to see that *-minimal is actually in aur. wouldn't it be natural to see *-with-* support in aur?

Last edited by taylorchu (2011-09-18 18:51:05)

lifeafter2am · 2011-09-18 18:53:24

taylorchu wrote:

@lifeafter2am
if it breaks dependency at compile time, it should surly go to [makedepend].
if it breaks dependency at run time, it should surly go to [depend]
But sometimes official packages enable some flags to have features, which is less "vanilla". "having less flags" or "having flags that result in less depends" is better.
@karol
yup. I know such thing exists. But I am discussing the official packages.

You misunderstood me; as I was not all that clear. Lets say a package can be compiled with mplayer support (a flag as you say). If you enable this flag you have to have mplayer as dependency. In order to not use mplayer, the binary needs to be recompiled with that flag disabled. That means that in the official repo you would have 2 different binaries: one with mplayer flag, and one without mplayer flag.

wonder · 2011-09-18 19:06:13

so lets talk about mplayer. what support is useless and you want it out?

taylorchu · 2011-09-18 19:27:59

@lifeafter2am
in that case, if ./configure use mplayer by default, then add mplayer as dependency. otherwise, do not enable any flag to add mplayer as feature. As a result, there should be only one package that uses upstream recommended dependencies.

Personally, I think the rule should be (in order):
1. use default configuration
2. to override rule1, flags should be used to reduce unwanted dependencies.
3. to make rule2 possible and flexible, use dynamic linking if required whenever possible

@wonder
I have to re-read upsteam doc. BTW, mplayer is just one package I can think of that have lots of dependencies. It is mentioned as an example.

Awebb · 2011-09-18 19:28:54

Before the foggy guessing about mplayer starts, here the facts:

Deps of mplayer:

    a52dec
    aalib
    cdparanoia
    desktop-file-utils
    enca
    faac
    faad2
    fontconfig
    fribidi
    jack
    lame
    libass
    libcaca
    libdca
    libgl
    libjpeg (libjpeg-turbo)
    libmad
    libmng
    libpulse
    libtheora
    libvdpau
    libvpx
    libxinerama
    libxss
    libxvmc
    libxxf86dga
    libxxf86vm
    lirc-utils
    mpg123
    opencore-amr
    schroedinger
    sdl
    smbclient
    ttf-dejavu
    x264
    xvidcore

pactree:

$ pactree mplayer
|--mplayer
   |--desktop-file-utils
      |--glib2
         |--pcre
            |--gcc-libs
               |--glibc
                  |--linux-api-headers
                  |--tzdata
   |--ttf-dejavu
      |--fontconfig
         |--expat
            |--glibc
         |--freetype2
            |--zlib
               |--glibc
      |--xorg-fonts-encodings
      |--xorg-mkfontscale
         |--freetype2
         |--libfontenc
            |--zlib
      |--xorg-mkfontdir
         +--bash provides sh
            |--readline
               |--glibc
               |--ncurses
                  |--glibc
            |--glibc
         |--xorg-mkfontscale
   |--enca
      |--recode
         |--glibc
         |--texinfo
            |--ncurses
            |--findutils
               |--glibc
               +--bash provides sh
            |--gzip
               |--glibc
               |--bash
      +--bash provides sh
   |--libxss
      |--libxext
         |--libx11
            |--libxcb
               |--xcb-proto
               |--libxdmcp
                  |--xproto
                  |--glibc
               |--libxau
                  |--glibc
                  |--xproto
            |--xproto
            |--kbproto
         |--xextproto
      |--scrnsaverproto
   |--a52dec
      |--glibc
   |--libvpx
      |--glibc
   |--lirc-utils
      |--alsa-lib
         |--glibc
      |--libx11
      |--libftdi
         |--libusb-compat
            |--libusb
               |--glibc
            +--bash provides sh
         |--gcc-libs
      |--libirman
         |--glibc
   |--x264
      |--glibc
   |--libmng
      |--zlib
      +--libjpeg-turbo provides libjpeg
         |--glibc
   |--libdca
      +--bash provides sh
   |--aalib
      |--glibc
      |--ncurses
      |--gpm
         |--ncurses
         |--bash
      |--libx11
   |--lame
      |--ncurses
   |--fontconfig
   +--nvidia-utils provides libgl
      |--xorg-server
         |--libxdmcp
         |--libxfont
            |--freetype2
            |--libfontenc
            |--xproto
            |--fontsproto
         |--udev
            |--glibc
            |--coreutils
               |--glibc
               |--shadow
                  |--bash
                  |--pam
                     |--glibc
                     |--db
                        |--gcc-libs
                        +--bash provides sh
                     |--cracklib
                        |--glibc
                        |--zlib
                     |--libtirpc
                        |--libgssglue
                           |--glibc
                  |--acl
                     |--attr
                        |--glibc
               |--pam
               |--acl
               |--gmp
                  |--gcc-libs
                  +--bash provides sh
               |--libcap
                  |--glibc
                  |--attr
            |--util-linux
               |--filesystem
                  |--iana-etc
                  |--bash
                  |--coreutils
            |--libusb-compat
            |--glib2
            |--module-init-tools
               |--glibc
            |--pciutils
               |--glibc
         |--libpciaccess
            |--glibc
         |--libdrm
            |--glibc
            |--libpciaccess
         |--pixman
            |--glibc
         |--libgcrypt
            |--libgpg-error
               |--glibc
               +--bash provides sh
         |--libxau
         |--xorg-server-common
            |--xkeyboard-config
               |--xorg-xkbcomp
                  |--libxkbfile
                     |--libx11
            |--xorg-xkbcomp
            |--xorg-setxkbmap
               |--libxkbfile
            |--xorg-fonts-misc
               |--xorg-fonts-encodings
               |--xorg-fonts-alias
               |--xorg-font-utils
                  |--xorg-bdftopcf
                     |--libxfont
                  |--xorg-mkfontdir
                  |--xorg-mkfontscale
                  |--xorg-font-util
               |--fontconfig
         |--xf86-input-evdev
            |--glibc
      |--libxvmc
         |--libxv
            |--libxext
            |--videoproto
      |--opencl-nvidia
         |--libcl
            |--gcc-libs
   |--libxinerama
      |--libxext
      |--xineramaproto
   |--libvdpau
      |--gcc-libs
   |--libpulse
      |--dbus-core
         |--expat
         |--coreutils
         |--filesystem
      |--xcb-util
         |--libxcb
      |--libasyncns
         |--glibc
      |--libcap
      |--libxtst
         |--libxext
         |--libxi
            |--libxext
            |--inputproto
         |--recordproto
         |--inputproto
      |--libsm
         |--libice
            |--glibc
            |--xproto
         +--util-linux provides util-linux-ng
      |--libsndfile
         |--alsa-lib
         |--flac
            |--libogg
               |--glibc
         |--libvorbis
            |--libogg
   |--smbclient
      |--readline
      |--popt
         |--glibc
      |--libldap
         |--libsasl
            |--openssl
               |--perl
                  |--gdbm
                     |--glibc
                     +--bash provides sh
                  |--db
                  |--coreutils
                  |--glibc
                  +--bash provides sh
         |--libfetch
            |--openssl
         |--e2fsprogs
            +--bash provides sh
            +--util-linux provides util-linux-ng
      |--cifs-utils
         |--libcap
         |--keyutils
            |--glibc
            +--bash provides sh
         |--krb5
            |--e2fsprogs
            |--libldap
            |--keyutils
         |--talloc
            |--glibc
      |--libcap
      |--krb5
      |--db
      |--e2fsprogs
      |--tdb
      |--talloc
   |--xvidcore
      |--glibc
   |--opencore-amr
      |--gcc-libs
   |--jack
      |--libsamplerate
         |--libsndfile
      |--readline
   |--cdparanoia
      |--glibc
   |--libmad
      |--glibc
   |--sdl
      |--glibc
      |--libxext
      |--libxrender
         |--libx11
         |--renderproto
      |--libx11
   |--libtheora
      |--libogg
   |--libcaca
      |--imlib2
         |--libtiff
            +--libjpeg-turbo provides libjpeg
            |--zlib
         |--giflib
            |--libx11
         |--bzip2
            |--glibc
         |--freetype2
         |--libxext
         |--libpng
            |--zlib
            +--bash provides sh
         |--libid3tag
            |--zlib
         |--libjpeg-turbo
      |--ncurses
   |--libxxf86dga
      |--libxext
      |--xf86dgaproto
   |--fribidi
      |--glibc
   +--libjpeg-turbo provides libjpeg
   |--faac
      |--libmp4v2
         |--gcc-libs
      |--glibc
   |--faad2
      |--glibc
   |--libxvmc
   |--schroedinger
      |--orc
         |--glibc
   |--mpg123
      |--libtool
         +--bash provides sh
         |--libltdl
         |--gcc
            |--gcc-libs
            |--binutils
               |--glibc
               |--zlib
            |--libmpc
               |--mpfr
                  |--gmp
            |--cloog
               |--isl
               |--gmp
            |--ppl
               |--gmp
      |--alsa-lib
   |--libass
      |--enca
      |--fontconfig
      |--libpng
   |--libxxf86vm
      |--libxext
      |--xf86vidmodeproto

I can see that only a certain group of users either use vdpau and/or pulseaudio. I also see that there are two dependencies only for ascii art stuff. I don't understand, why it needs desktop-file-utils, I can't imagine, why I want mplayer to do that, but someone might have put some thought in this. So besides vdpau (which I'm glad it has) and pulseaudio (okay, and the cool ascii stuff), I don't see much that isn't needed to play the big list of wide spread media file formats. Maybe jack, but I haven't had a look at why jack is used.

I don't mind those deps. I want mplayer to do everything. I found it anoying that it wasn't compiled with network support for so long (or I did something wrong, now it works), I mean... it's 2011, network support for mplayer should be mandatory. According to my opinion at least. But I can understand the pain some people have with this, everytime I see a *gnome* dep anywhere, I don't want the package anymore and look for something else.

karol · 2011-09-18 19:43:27

For example smbclient is a pretty big package I don't have any use for. Compiling mplayer takes quite some time (especially on my slow gear) but I can use e.g. mplayer-svn 32524-1 from [archstuff] or decide that 100MB more packages is not a terrible price to pay for fresh binaries.

lolilolicon · 2011-09-18 19:43:52

taylorchu wrote:

<...> "having flags that result in less depends" is better.

I wouldn't say that. IMHO, consistency with upstream "intended features", feature popularity among Arch users, and package maintainer personal preferences determine the packaging, rather than targeting a minimal set of dependencies.

Many minimal- packages are done by adding additional flags to disable default features, which many would want. As a user, I'd definitely love to see everything to fit just exactly my needs, which is impossible... so, realistically I prefer "bloat but feature complete" to "minimal but broken for me". In the end, my system will always be sort of bloat, from the kernel to mplayer... the monsters...

wonder · 2011-09-18 19:46:00

desktop-file-utils has update-desktop-database. i guess everyone wants mplayer to be detected as a valid media player for different file types no?

Last edited by wonder (2011-09-18 19:50:58)

karol · 2011-09-18 19:49:13

wonder wrote:

desktop-file-utils has update-desktop-database. i guess everyone wants mplayer to be detected as a valid media player for different file types no?:)

I'm using the commandline, so should I care about .desktop entries?

wonder · 2011-09-18 19:51:45

karol wrote:

wonder wrote:
desktop-file-utils has update-desktop-database. i guess everyone wants mplayer to be detected as a valid media player for different file types no?:)
I'm using the commandline, so should I care about .desktop entries?

who cares if you use command line. we are in 2011, we expect at least media players to be detected as a valid option when double clicking on files!

let me know what features you like most from mplayer so i can get rid of them now.

Last edited by wonder (2011-09-18 19:52:55)

Awebb · 2011-09-18 19:55:19

@wonder: Makes sense... the valid player thing... not the 2011 thing. I pull this one ten times a day (especially in social situations) so I sort of forgot the meaning :-D

EDIT: Haha, I somehow like you people from Romania ^^

Last edited by Awebb (2011-09-18 19:56:13)

taylorchu · 2011-09-18 20:00:58

Thats the point. Arch devs should not let a package to have too many dependencies. Not only it causes bloatness of this particular package but the packages that depend on it. Anyway, dependencies should be re-checked.

use Awebb's pactree as an example, I want to watch video, so I installed mplayer, which is claimed to be lightweight. But mplayer depends on mpg123, which depends on gcc. I end up installing gcc when I just need to watch video with common encoding like avi. x264. use pacman -S on other big packages, you will be really likely to see some random craps. as I said, just few codecs could do the job.

karol · 2011-09-18 20:02:09

mpg123 does not depend on gcc ...

taylorchu · 2011-09-18 20:06:16

@karol
it is why we should check dependencies from bottom-up.

 |--mpg123
      |--libtool
         +--bash provides sh
         |--libltdl
         |--gcc
            |--gcc-libs
            |--binutils
               |--glibc
               |--zlib
            |--libmpc
               |--mpfr
                  |--gmp
            |--cloog
               |--isl
               |--gmp
            |--ppl
               |--gmp

wonder · 2011-09-18 20:08:38

@taylorchu you don't have a good view of how packaging works. mpg123 doesn't depend on gcc, libtool does. You can report on the tracker to change the dependency from libtool to libltdl.

again, your needs doesn't match my needs or other users.

karol · 2011-09-18 20:09:20

@taylorchu
See https://bugs.archlinux.org/task/14903 for similar discussion:

Pierre Schmitz (Pierre) wrote:

Removing a dep from such a basic pacakge means that we need to recheck all deps of packages that directly or indirectly depend on openssl.

If you start digging deep, playing around with gcc and friends, you need to make sure that everything that worked before your changes will still work after you excluded some package here and another there.

@wonder

wonder wrote:

karol wrote:
wonder wrote:
desktop-file-utils has update-desktop-database. i guess everyone wants mplayer to be detected as a valid media player for different file types no?:)
I'm using the commandline, so should I care about .desktop entries?
who cares if you use command line. we are in 2011, we expect at least media players to be detected as a valid option when double clicking on files!

That's the response I wanted to hear: If I really don't need them, I can take them out myself :-)

Last edited by karol (2011-09-18 20:12:40)

lolilolicon · 2011-09-18 20:15:34

Yeah libltdl has been split from libtool just recently, so such bugs are to be expected.

taylorchu · 2011-09-18 20:32:58

@karol

If you start digging deep, playing around with gcc and friends, you need to make sure that everything that worked before your changes will still work after you excluded some package here and another there.

since pacman offers dep resolv, it is a tiresome but required job. i think it is beneficial in the long run. if i were a dev, I would read upstream doc that states required {build, runtime} dependencies. and add more dependencies if they fit. most upstream websites have this kind of information; if it does not, it is worthy to email upstream developers to add it.

Allan · 2011-09-18 22:01:28

If you were a helpful user, you would have filed the bug report about mpg123 depending on libtool rather than libltdl and that would result in gcc being removed from the dependency chain. Complaining on the forums gets you nowhere.

mhertz · 2011-09-18 22:38:32

I think that it would make best sence to use the standard upstream supplied configure scripts, and if users have other needs, then they could built it themselves...

Arch Linux

#1 2011-09-18 18:21:01

arch's weakness: dependency resolving

#2 2011-09-18 18:25:44

Re: arch's weakness: dependency resolving

#3 2011-09-18 18:26:33

Re: arch's weakness: dependency resolving

#4 2011-09-18 18:28:56

Re: arch's weakness: dependency resolving

#5 2011-09-18 18:35:29

Re: arch's weakness: dependency resolving

#6 2011-09-18 18:45:44

Re: arch's weakness: dependency resolving

#7 2011-09-18 18:53:24

Re: arch's weakness: dependency resolving

#8 2011-09-18 19:06:13

Re: arch's weakness: dependency resolving

#9 2011-09-18 19:27:59

Re: arch's weakness: dependency resolving

#10 2011-09-18 19:28:54

Re: arch's weakness: dependency resolving

#11 2011-09-18 19:43:27

Re: arch's weakness: dependency resolving

#12 2011-09-18 19:43:52

Re: arch's weakness: dependency resolving

#13 2011-09-18 19:46:00

Re: arch's weakness: dependency resolving

#14 2011-09-18 19:49:13

Re: arch's weakness: dependency resolving

#15 2011-09-18 19:51:45

Re: arch's weakness: dependency resolving

#16 2011-09-18 19:55:19

Re: arch's weakness: dependency resolving

#17 2011-09-18 20:00:58

Re: arch's weakness: dependency resolving

#18 2011-09-18 20:02:09

Re: arch's weakness: dependency resolving

#19 2011-09-18 20:06:16

Re: arch's weakness: dependency resolving

#20 2011-09-18 20:08:38

Re: arch's weakness: dependency resolving

#21 2011-09-18 20:09:20

Re: arch's weakness: dependency resolving

#22 2011-09-18 20:15:34

Re: arch's weakness: dependency resolving

#23 2011-09-18 20:32:58

Re: arch's weakness: dependency resolving

#24 2011-09-18 22:01:28

Re: arch's weakness: dependency resolving

#25 2011-09-18 22:38:32

Re: arch's weakness: dependency resolving

Board footer