arch's weakness: dependency resolving

ethail · 2011-09-19 06:31:32

I say let's stop ranting about "I don't need this stuff" and convert that useless whining time into DIY packaging time, shall we?

If you don't need that or this stuff, just repackage it yourself without that, what is the ABS for ?
"Downgrading"? bullshit

If it doesn't make you happy, but it fits for the majority of us: You have my condolences.

The repos and their packaging way is meant to be consistent, not to make all people liking it. If you changes deps on one package, you'll have to make sure it works on all packages depending of that, and all depending of the dependants, an so on. In short, changing one package doesn't mean you're done, you have to check all levels of deps in a binary distro.

Do you want it your way? ABS or AUR
Do you think it is needed/wanted by more people? Post a feature request, don't do this kind of ranting if you want to reach devs.

As last chance, go to a source based distros.

swanson · 2011-09-19 09:23:46

on a sidenote; other distros wich are non-rolling results in a "lock-in" of certain versions and if you want something newer installed, you can end up in dependency-hell. Even if you compile stuff yourself. With Arch repos and AUR it is much more flexible in my opinion.

Runiq · 2011-09-19 11:16:33

taylorchu wrote:

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.

I reckon any packagers worth their salt do this already. Making sure a package works without adding unnecessary dependencies is one part of the packager's job description.

However, another part is to tailor the package to most of the users' necessities, which is what's going on with mplayer. If you don't like it that way: Stop whining and start packaging, as ethail put it.

Awebb · 2011-09-19 11:31:52

The question is: Would mplayer work flawlessly without, say, libvdpau installed, even if it was compiled towards libvdpau? In this case, it would be easy to either push some packages to the optional deps or manually and forcefully removing them after installing mplayer. Worth a try...

keenerd · 2011-09-19 11:31:55

I'd just like to point out that raising bug reports for silly dependencies often gets nowhere. My personal itch is our OpenSSL package.

OpenSSL depends on Perl. Why? There is a single perl script, /etc/ssl/misc/CA.pl in it. I've never used this script, it is entirely optional. Even more annoying, there is /etc/ssl/misc/CA.sh which is the exact same script ported to bash. It is entirely redundant and there is no reason to depend on Perl.

I dug through the OpenSSL dev mailing lists to try to find why they have a bash and perl version of the same script. Turns out perl is a lot easier to install on Windows than bash is. (You'd need an entire Cygwin install to cover everything that can happen in a bash script.) So our OpenSSL drags in perl for better windows compatibility. You know, in case you are running pacman on windows.

Last edited by keenerd (2011-09-19 11:34:10)

karol · 2011-09-19 13:58:48

keenerd wrote:

I'd just like to point out that raising bug reports for silly dependencies often gets nowhere. My personal itch is our OpenSSL package.

That's my favorite too :-)

Have you tried removing perl dep? Did something (that depends on openSSL) break? If everything is working fine, you can use ABS to fix it as you like.

Last edited by karol (2011-09-19 13:59:29)

schivmeister · 2011-09-19 15:30:43

Arch Linux provides you with one, just one package per software, unless otherwise required. This is KISS, because when you ******* ask your package manager to ******* install "foo", it ******* installs foo, and when you ******* search for "foo", you ******* get foo.

Arch Linux packagers have it in their duty to ensure:

1. The packaged software functions as intended by the (upstream) developer(s) of the software

This also encompasses:

1.1 The package has appropriate dependencies to satisfy {1}

1.2 The packaged software's functionality serves the majority of users while satisfying {1} and {1.1}

1.3 In the event there is a mistake in the dependency list of a package, the packager may be informed

1.3.1 Inform the packager of an ammendment to a package by the way of filing a bug report

1.3.2 Provide adequate reasoning and citation if it is not obvious why the ammendment is necessary

This doesn't need to be in black and white, because competent users who are competent enough to use Arch Linux or Slackware should understand this.

Our wine package depends on jack because it's a link-level dependency once you build against it (and to provide jack support you must build against it), and most importantly, because we don't split jack into libjack and jackd. We've never received any complaint or request to do such a split, and even if we did, there wasn't enough justification, ever. There are enough complaints and justification against pulseaudio, for example, so we have libpulse.

Many GTK+ apps and utilities claim to be GTK+ apps and utilities but depend on GNOME-specific apps and utilities. This is not our fault, we just make the fact obvious to you. Please take your whining upstream. If the dependency list can indeed be cleaned up, we want to see bug reports. We're not carebears - we don't go around looking for people to take care of.

edit: censored words not safe for kids

Last edited by schivmeister (2011-09-19 17:35:32)

karol · 2011-09-19 15:34:45

taylorchu opened a bug report https://bugs.archlinux.org/task/26063 wrt libltdl v. libtool dependencies.

taylorchu · 2011-09-19 15:40:16

@ethail
the problem is addressed by Awebb. It is not that mplayer has too many dependencies that I dont like. (mplayer is just an example.)

Problems to discuss:
1. should we put more depend to optdepend? (good point from @keenerd)
2. whether point 1 causes runtime problems or crashes? (from @Awebb)
3. should we put more efforts on dependency checking?

telling one to make aur, abs, compile it your own is not going to help this community after all. I can do this myself, but if they are good points why not make them official?

Gusar · 2011-09-19 15:45:59

karol wrote:

That's my favorite too :-)
Have you tried removing perl dep? Did something (that depends on openSSL) break? If everything is working fine, you can use ABS to fix it as you like.

ca-certificates and everything that uses it will potentially break without perl, because it uses c_rehash (a perl script distributed with openssl) to create all the symlinks in /etc/ssl/certs. But a simple google search and I found a maintained shell version of c_rehash - http://cvs.pld-linux.org/cgi-bin/cvsweb … s/openssl/
You could do an experiment: Replace c_rehash with the shell version from that link. Delete (or move out of the way) the contents of /etc/ssl/certs and reinstall ca-certificates. Check if /etc/ssl/certs has been created the same way as before. Just one thing before you start - modify the script, it says /etc/openssl towards the top, change that to /etc/ssl

When it comes to mplayer, you can compile a pretty much standalone binary that plays everything and has no external dependencies beyond common X stuff. I do it like that and have forever. I'm sure there's PKGBUILD in AUR that automate it.

And as for the general topic of the thread, it's not Arch's weakness, it's a weakness of binary distros. The one sorta possible solution is multiple packages for the same app, but the potential to create a dependency nightmare is way too big to go that route.

Last edited by Gusar (2011-09-19 15:53:24)

wonder · 2011-09-19 15:47:38

@taylorchu let me explain how i package gnome.

i remove all dependencies and when configure fails because it's missing a dependency, i add it. It's not only valid in gnome but in our packages in general. This is how upstream wanted to be.

mplayer is a bit special, all tests are autodetected and the feature is enabled if dependency is met. I don't enable explicitly some features.

taylorchu · 2011-09-19 16:02:20

@wonder
that's great. strive for the minimal for makedepends. after compiling, will the package work(no crash) without putting in depends?

mplayer is a bit special, all tests are autodetected and the feature is enabled if dependency is met. I don't enable explicitly some features.

yup. it depends on what you put in makedepends.

karol · 2011-09-19 16:03:23

@Gusar
A shell version of c_rehash is even mentioned in the bug report, but the version you linked to offers some gentle improvements.

Gusar wrote:

Just one thing before you start - modify the script, it says /etc/openssl towards the top, change that to /etc/ssl

Thanks for the heads-up :-)

How big is your mplayer binary?

tomk · 2011-09-19 16:20:41

taylorchu - no offense, but the dumb youtube rant (that's what he called it) that started this thread was posted over 18 months ago, and was discussed before. If you have specific examples of dependencies that you believe are unnecessary please post them.

If I was a dev, I would find your posts here offensive, as you seem to be assuming that there are unnecessary dependencies simply because you stumbled across that youtube nonsense.

ewaller · 2011-09-19 17:09:02

Moderator Comment:

tomk wrote:

...If I was a dev, I would find your posts here offensive, as you seem to be assuming that there are unnecessary dependencies simply because you stumbled across that youtube nonsense.

I agree. As a moderator, I insist this thread be kept civil. Please reread Forum etiquette regarding the staff

I would also encourage my colleagues not to let members forum get under your skin. Stay above the fray.

Gusar · 2011-09-19 17:13:14

karol wrote:

How big is your mplayer binary?

It's mplayer2 actually, which allows greater control over which parts of the internal ffmpeg get compiled, and it's 6.8MB. It's a few months old too, that possibly has an impact. The last time I compiled mplayer (quite a long time ago) it was 8.9MB I think.

So, have you tried the shell c_rehash version yet? Did it blow up your computer?

wonder · 2011-09-19 17:19:09

@Gusar don't be fooled by the size. mplayer2 uses external ffmpeg and mplayer has it's own internal statically linked version. In the end by using mplayer2, you will end up using more space

karol · 2011-09-19 17:19:18

Gusar wrote:

karol wrote:
How big is your mplayer binary?
It's mplayer2 actually, which allows greater control over which parts of the internal ffmpeg get compiled, and it's 6.8MB. It's a few months old too, that possibly has an impact. The last time I compiled mplayer (quite a long time ago) it was 8.9MB I think.
So, have you tried the shell c_rehash version yet? Did it blow up your computer?

I'm using mplayer2 from [community] http://www.archlinux.org/packages/commu … /mplayer2/ which is 6.6 MB (+ dependencies).
Mind sharing your PKGBUILD?

I'll try the perl-less setup tomorrow. I have two computers so even if one blows up, I'll still be able to report the fiasco ;P

Edit: I think wonder is right about the size although by using mpleyr2 I don't have to install smbclient :-)

Last edited by karol (2011-09-19 17:22:34)

Gusar · 2011-09-19 17:53:17

wonder wrote:

@Gusar don't be fooled by the size. mplayer2 uses external ffmpeg

Not when I compile it

@karol: No PKGBUILD, but manual compilation and them manual copying of the binary into /usr/local/bin

This is ffmpeg_options:

# You can place options for FFmpeg configure in this file.

# Place each option on its own line. Empty lines and lines starting with '#'
# are ignored. The options do not need quoting, so you can have for example
# --extra-libs=-lfoo -lbar
# (and NOT --extra-libs='-lfoo -lbar').

--disable-bsfs
--disable-encoders
--disable-protocols
--disable-filters
--disable-muxers
--disable-avdevice
--disable-avfilter
--disable-network
--enable-encoder=png

and mplayer_options:

# You can place options for MPlayer configure in this file.

# Place each option on its own line. Empty lines and lines starting with '#'
# are ignored. The options do not need quoting, so you can have for example
# --extra-libs=-lfoo -lbar
# (and NOT --extra-libs='-lfoo -lbar').

--disable-gif
--disable-png
--disable-mng
--disable-pnm
--disable-tga
--disable-jpeg
--disable-real
--disable-qtx
--disable-xanim
--disable-libvorbis
--disable-yuv4mpeg
--disable-matrixview
--disable-md5sum
--disable-ftp
--disable-sdl

This way there's very few external dependencies, so the same binary will work pretty much forever.

Last edited by Gusar (2011-09-19 18:01:29)

lifeafter2am · 2011-09-19 19:01:14

tomk wrote:

tIf I was a dev, I would find your posts here offensive, as you seem to be assuming that there are unnecessary dependencies simply because you stumbled across that youtube nonsense.

This.

taylorchu · 2011-09-20 05:40:19

@everyone
sorry for the bad video. @tomk

karol wrote:

taylorchu opened a bug report https://bugs.archlinux.org/task/26063 wrt libltdl v. libtool dependencies.

could anyone help to check what package can use libltdl? (yes for able to use libtldl; no for not possible)
pulseaudio yes
libcanberra yes
redland yes

Grinch · 2011-09-20 15:05:27

Well, I've personally always been a 'less is more' type of guy so I definately prefer leaner packages. That said, from a packager perspective I understand fully that they aren't very eager to experiment with the least amount of dependencies, given that it may very well come back to bite them with users complaining that this and that 'no longer works as it should' (tm). Given that we have ABS, not to mention AUR, it's not like we don't have options.

Packagers are doing an enourmous community service, standing on the sidelines and nitpicking their efforts is probably not at all constructive and likely only serves to lower their morale. If you have issue with a package's dependencies, why not create an AUR version of it and inform people (and the official package maintainer) of it's existence. If it's popular enough and isn't causing any regressions chances are those dependencies will be used in the official package. For example I recently came across this package which removes nautilus as a dependancy for file-roller: https://aur.archlinux.org/packages.php?ID=52164

karol · 2011-09-20 22:11:42

Gusar wrote:

You could do an experiment: Replace c_rehash with the shell version from that link. Delete (or move out of the way) the contents of /etc/ssl/certs and reinstall ca-certificates. Check if /etc/ssl/certs has been created the same way as before.

Done. The shell script seems to be working - it recreated the contents of /etc/ssl/certs, symlinks and stuff.

Gusar · 2011-09-21 09:30:57

karol wrote:

Gusar wrote:
You could do an experiment: Replace c_rehash with the shell version from that link. Delete (or move out of the way) the contents of /etc/ssl/certs and reinstall ca-certificates. Check if /etc/ssl/certs has been created the same way as before.
Done. The shell script seems to be working - it recreated the contents of /etc/ssl/certs, symlinks and stuff.

Sweet. Now, what are the chances we could convince Arch developers to switch to that script and drop the perl dependency of openssl?

ngoonee · 2011-09-21 09:51:14

Gusar wrote:

karol wrote:
Gusar wrote:
You could do an experiment: Replace c_rehash with the shell version from that link. Delete (or move out of the way) the contents of /etc/ssl/certs and reinstall ca-certificates. Check if /etc/ssl/certs has been created the same way as before.
Done. The shell script seems to be working - it recreated the contents of /etc/ssl/certs, symlinks and stuff.
Sweet. Now, what are the chances we could convince Arch developers to switch to that script and drop the perl dependency of openssl?

You'd have to try it to find out. Bug report + ready patches + rationale.

Arch Linux

#26 2011-09-19 06:31:32

Re: arch's weakness: dependency resolving

#27 2011-09-19 09:23:46

Re: arch's weakness: dependency resolving

#28 2011-09-19 11:16:33

Re: arch's weakness: dependency resolving

#29 2011-09-19 11:31:52

Re: arch's weakness: dependency resolving

#30 2011-09-19 11:31:55

Re: arch's weakness: dependency resolving

#31 2011-09-19 13:58:48

Re: arch's weakness: dependency resolving

#32 2011-09-19 15:30:43

Re: arch's weakness: dependency resolving

#33 2011-09-19 15:34:45

Re: arch's weakness: dependency resolving

#34 2011-09-19 15:40:16

Re: arch's weakness: dependency resolving

#35 2011-09-19 15:45:59

Re: arch's weakness: dependency resolving

#36 2011-09-19 15:47:38

Re: arch's weakness: dependency resolving

#37 2011-09-19 16:02:20

Re: arch's weakness: dependency resolving

#38 2011-09-19 16:03:23

Re: arch's weakness: dependency resolving

#39 2011-09-19 16:20:41

Re: arch's weakness: dependency resolving

#40 2011-09-19 17:09:02

Re: arch's weakness: dependency resolving

#41 2011-09-19 17:13:14

Re: arch's weakness: dependency resolving

#42 2011-09-19 17:19:09

Re: arch's weakness: dependency resolving

#43 2011-09-19 17:19:18

Re: arch's weakness: dependency resolving

#44 2011-09-19 17:53:17

Re: arch's weakness: dependency resolving

#45 2011-09-19 19:01:14

Re: arch's weakness: dependency resolving

#46 2011-09-20 05:40:19

Re: arch's weakness: dependency resolving

#47 2011-09-20 15:05:27

Re: arch's weakness: dependency resolving

#48 2011-09-20 22:11:42

Re: arch's weakness: dependency resolving

#49 2011-09-21 09:30:57

Re: arch's weakness: dependency resolving

#50 2011-09-21 09:51:14

Re: arch's weakness: dependency resolving

Board footer