You are not logged in.

#51 2011-09-21 11:24:17

Mr.Elendig
#archlinux@freenode channel op
From: The intertubes
Registered: 2004-11-07
Posts: 4,092

Re: arch's weakness: dependency resolving

ngoonee wrote:
Gusar wrote:
karol wrote:

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.

Or even better, try to get upstream to move away from perl. (good luck with that though)


Evil #archlinux@libera.chat channel op and general support dude.
. files on github, Screenshots, Random pics and the rest

Offline

#52 2011-09-21 12:35:13

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: arch's weakness: dependency resolving

perl is needed for many basic packages so, just as it was said in the bug report:

Gerardo Exequiel Pozzi (djgera) wrote:

This is very interesting for minimal chroot for example

but may not benefit your "full install" as dev tools like git and automake depend on perl. groff, iproute2 and vim-runtime need perl too - iproute2 is required by initscripts.

Offline

#53 2011-09-21 13:31:21

toofishes
Developer
From: Chicago, IL
Registered: 2006-06-06
Posts: 602
Website

Re: arch's weakness: dependency resolving

karol wrote:

perl is needed for many basic packages so, just as it was said in the bug report:

Gerardo Exequiel Pozzi (djgera) wrote:

This is very interesting for minimal chroot for example

but may not benefit your "full install" as dev tools like git and automake depend on perl. groff, iproute2 and vim-runtime need perl too - iproute2 is required by initscripts.

It doesn't even need to be a full install- a minimal useful chroot is usually used for building packages, and given that automake depends on perl, this doesn't help at all.

Offline

#54 2011-09-21 14:05:22

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: arch's weakness: dependency resolving

I was thinking more of a very minimal install. Not a chroot for some specific purpose (like building packages), simply a small but still fully usable install. Though here I can already see the obvious argument - "disk space is cheap" - which I guess is quite valid in times where it's, for example, impossible to buy an usb-stick smaller than 2GB. But I do have and use a 64MB stick.

Interesting that iproute2 depends on perl, didn't know that. So it's actually quite hard to have an Arch install without perl. I suppose it's possible to just not use any network stuff initscripts provide, and then there's busybox.

Meh, this is all more of an academic exercise anyway. But hey, why not. We did learn one tiny thing, that the openssl/ca-certificates combo does have a perl-less alternative.
To continue the academic exercise... where does iproute2 need perl? It doesn't ship with any perl scripts and none of it's binaries depend on libperl.

Last edited by Gusar (2011-09-21 16:35:56)

Offline

#55 2011-09-21 16:20:02

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: arch's weakness: dependency resolving

I think the openssl perl-less setup was for routers, where space is/was limited. The script mentioned in the bug report http://mail-index.netbsd.org/tech-crypt … /0000.html is from 2005 when memory cards / usb sticks were still pretty small and expensive.

Offline

#56 2011-09-25 20:06:40

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: arch's weakness: dependency resolving

Interesting thread. I like responsible use of "dlopen" as I see that as the best of both worlds. But rewriting every program to use it would obviously be a huge waste of effort for Arch.

I scrutinize every install list that "pacman -Syu" gives me and when I see a dependency in there that I haven't seen before, I find out what package is pulling it in and try to decide whether or not it is really needed. There really are cases where an Arch package has a pointless dependency.

1. gstreamer0.10-good-plugins depends on gconf because of one file: libgstgconfelements.so, even though realistically, a program that depends on the good-plugins will be using the codecs and not give a rat's ass about the gconf elements. It also used to have libgsthalelements.so making it depend on hal.

2. Just about everything in Xfce that claims to depend on consolekit really doesn't. Using xfce without it will make it fall back to sudo.

3. One I find laughable is that matplotlib tries to bring in all of qt but the powers that be said no to changing that.

For a time, I even used a dummy PKGBUILD to get around these annoyances:

pkgname=dummy
pkgver=1.0
pkgrel=1
pkgdesc="Tells pacman I have what it wants me to have but don't need"
arch=(i686 x86_64)
provides=('hal=999' 'consolekit=999' 'policykit=999' 'polkit=999' 'rtkit=999' 'upower=999' 'gconf=999' 'libsoup-gnome=999' 'esound=999' 'gnome-icon-theme=999' 'python2-qt=999')

build()
{
	echo "DONE"
}

license=('GPL')
md5sums=()

That's probably a bad idea but as time goes on but it seems like Arch users are having to become more and more vigilant. If I didn't use a fair number of perl programs, the perl dependency in openssl would definitely raise a red flag with me. Mplayer codecs, I am more okay with because who knows what strange type of video I might try to play in the future?


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#57 2011-11-29 16:30:20

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: arch's weakness: dependency resolving

Has anyone tried to make emacs' dependencies saner?
https://bbs.archlinux.org/viewtopic.php?id=128731

Offline

#58 2011-11-29 16:50:42

sl1pkn07
Member
From: Spanishtán
Registered: 2010-03-30
Posts: 371

Re: arch's weakness: dependency resolving

wonder wrote:

@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 smile

sorry for this. this is backwards, mplayer2 uses internal libav(not ffmpeg) (see mplayer2-build.git) and mplayer uses external ffmpeg (i dont know change this)

Offline

#59 2011-11-29 16:56:16

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: arch's weakness: dependency resolving

sl1pkn07 wrote:
wonder wrote:

@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 smile

sorry for this. this is backwards, mplayer2 uses internal libav(not ffmpeg) (see mplayer2-build.git) and mplayer uses external ffmpeg (i dont know change this)

Our mplayer2 depends on ffmpeg http://projects.archlinux.org/svntogit/ … s/mplayer2

Offline

#60 2011-11-29 17:33:07

sl1pkn07
Member
From: Spanishtán
Registered: 2010-03-30
Posts: 371

Re: arch's weakness: dependency resolving

karol wrote:
sl1pkn07 wrote:
wonder wrote:

@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 smile

sorry for this. this is backwards, mplayer2 uses internal libav(not ffmpeg) (see mplayer2-build.git) and mplayer uses external ffmpeg (i dont know change this)

Our mplayer2 depends on ffmpeg http://projects.archlinux.org/svntogit/ … s/mplayer2

yes. that package. but not necessary. you are referring this:

mplayer2_site wrote:

mplayer2.git - Player only.

but I refer to this:

mplayer2_site wrote:

mplayer2-build.git - Helper that automatically builds new FFmpeg too. (recommended for most users)

this build mplayer2 without external ffmpeg. uses internal libav commits (see scripts)


the perfect build mplayer2 is like to this: http://aur.archlinux.org/packages.php?ID=46805 ( need add libbluray/-git[1][2] (for play decrypt blu-rays) and harfbuzz-git[3] (part of internal libass) opt/dependencies)


sorry my english

Offline

#61 2011-12-14 12:35:27

krum
Member
From: Grenoble - FR
Registered: 2008-04-10
Posts: 32

Re: arch's weakness: dependency resolving

Regarding the openssl perl dependency, the argument for closing the bug report is a bad and dangerous argument IMHO:

"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 a package explicitly needs perl (or another package), it needs to have a hard dep on this package and not rely on a "father package" for that.

Offline

#62 2011-12-14 12:46:25

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: arch's weakness: dependency resolving

I'm not sure if that's how dependencies work + perl is in the 'base' group and users are expected to have 'base' (and in some cases 'base-devel') installed so packages from these groups are generally not specified in depends (and makedepends for 'base-devel').

Offline

#63 2012-01-13 10:40:58

usagi
Member
Registered: 2011-11-21
Posts: 62

Re: arch's weakness: dependency resolving

I have a feeling that the moral here is:

If a user wants to remove deps, they're usually at a level where the ABS would come easy, and they could easily do it themselves.

OTOH, finding that a NEEDED dependancy for your use case is missing is infuriating. On top of that, locating and installing some obscure, but needed dependancy can be a *long* process. Go ahead, start with a base system and try to build a dep-heavy package from source, and you'll see what i mean.

Offline

#64 2012-01-13 11:15:09

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: arch's weakness: dependency resolving

usagi wrote:

Go ahead, start with a base system and try to build a dep-heavy package from source, and you'll see what i mean.

How is that different from any other distro? That's why we have PKGBUILDs and Debian has "apt-get build-dep" and Gentoo has ebuilds, etc.

Offline

#65 2012-01-13 12:04:45

tomk
Forum Fellow
From: Ireland
Registered: 2004-07-21
Posts: 9,839

Re: arch's weakness: dependency resolving

usagi wrote:

On top of that, locating and installing some obscure, but needed dependancy can be a *long* process.

Easy solution: don't use obscure applications. smile

usagi wrote:

Go ahead, start with a base system and try to build a dep-heavy package from source, and you'll see what i mean.

Don't know about you, but whenever I build something from source, I have this quirky little personal habit of reading the documentation first, to find out what deps I should install before I start the build.

Offline

#66 2012-01-13 12:05:55

karol
Archivist
Registered: 2009-05-06
Posts: 25,440

Re: arch's weakness: dependency resolving

tomk wrote:
usagi wrote:

On top of that, locating and installing some obscure, but needed dependancy can be a *long* process.

Easy solution: don't use obscure applications. smile

usagi wrote:

Go ahead, start with a base system and try to build a dep-heavy package from source, and you'll see what i mean.

Don't know about you, but whenever I build something from source, I have this quirky little personal habit of reading the documentation first, to find out what deps I should install before I start the build.

+1
I'm curious if you have any particular apps in mind.

Offline

#67 2012-01-13 19:38:51

ConnorBehan
Package Maintainer (PM)
From: Long Island NY
Registered: 2007-07-05
Posts: 1,359
Website

Re: arch's weakness: dependency resolving

The documentation would allow you to do a "pacman -S" for each dependency making the rest of the build easy. But it would be hard if you insist on building *each dependency* from source too.


6EA3 F3F3 B908 2632 A9CB E931 D53A 0445 B47A 0DAB
Great things come in tar.xz packages.

Offline

#68 2012-01-13 22:36:14

stefanwilkens
Member
From: Enschede, the Netherlands
Registered: 2008-12-10
Posts: 624

Re: arch's weakness: dependency resolving

I'd like to remind everybody that all the official packages have their PKGBUILDS available through ABS[1], all the tools and guides are in place (abundantly so even) for you to recompile application x with your preferred dependencies.

Some repo packages may come with dependencies for functionality you consider optional or unwanted, the solution is to grab the PKGBUILD through ABS and recompile to fit your personal needs. A great framework is in place to handle this, try sorting out something like this on Ubuntu and friends.. I assure you you'll need an extra pot of coffee.


[1] https://wiki.archlinux.org/index.php/ABS

p.s. the video is just silly, the reviewer obviously fails to understand the operating system he's using or even computing in general. Saying things like "a lot of formats require mp3" just makes me sad, as do the rest of his videos. In a way, the guy shows Arch isn't for everybody. This isn't new.


Arch i686 on Phenom X4 | GTX760

Offline

#69 2012-01-14 09:34:31

Awebb
Member
Registered: 2010-05-06
Posts: 6,272

Re: arch's weakness: dependency resolving

stefanwilkens wrote:

A great framework is in place to handle this, try sorting out something like this on Ubuntu and friends.. I assure you you'll need an extra pot of coffee.

There is a source repo in Debian AFAIK. If I got it right, you can simply download the src package, modify it, make it and then use checkinstall to create a rudimentary .deb. But I agree, ABS is somewhat superior.

Offline

#70 2012-01-14 10:42:04

Gusar
Member
Registered: 2009-08-25
Posts: 3,605

Re: arch's weakness: dependency resolving

Awebb wrote:

There is a source repo in Debian AFAIK. If I got it right, you can simply download the src package, modify it, make it and then use checkinstall to create a rudimentary .deb. But I agree, ABS is somewhat superior.

If you download a source .deb with "apt-get source", you don't use checkinstall, you run "debian/rules binary" to create a proper .deb. The only issue is, rules files are quite complex beasts, PKGBUILDs are notably simpler and therefore quite a bit easier to hack on.

Offline

Board footer

Powered by FluxBB