more and more circular deps....

[yoshi314]

reusing code, and using a piece of some software in another software is a good thing. i gotta agree. but it leads to bad results for people like us.

i tried today to put a new gentoo system. to my amazement i got into 2 circular deps situations.

one : USE="gif sdl"
xorg-server -> libsdl -> giflib -> xorg-server

giflib, even with "-X" use flag wants X via its deps somehow. i had to remove USE="gif" and i will have to rebuild libsdl later.

two: USE="cups qt3 qt4 dbus"
cups -> dbus -> qt3, qt4 -> cups
i decided to remove USE="dbus" for cups, because cups is the quickest to rebuild.

but you got to admit, it's a pain to build some packages twice :/

i wonder what awaits us in the future when more and more open-source software gets integrated with each other. ehh

i guess we will be sentenced to deal with those circular deps...forever :/

[Dralnu]

I'm all in favor of a set of basic libraries to use (kind of like Windows DLLs, for lack of a better refrence), and not relying on programs themselves unless they are a package series (Koffice, for instance).

The circular deps are annoying, admittedly, but until someone decides to start using a basic lib system, we're in for this for a good long while...

[Q-collective]

What is this "basic" library system and how basic would it be? Would it include X? And if not, would it exclude png aswell and thusly not support png's in framebuffer? (png *needs* X for example).
And if you would include everything, wouldn't the system become extremely heavy?

The rise of circular dependencies point us to the fact that the portage system needs to be thought over, I think that in the end that is the only solution.

[Dralnu]

What is this "basic" library system and how basic would it be? Would it include X? And if not, would it exclude png aswell and thusly not support png's in framebuffer? (png *needs* X for example).
And if you would include everything, wouldn't the system become extremely heavy?

The rise of circular dependencies point us to the fact that the portage system needs to be thought over, I think that in the end that is the only solution.

What I was thinking was like glibc. Alot of packages use it for some basic work, and like libkdebase.

What I was thinking about would be a set of core libs that could be used, and programs like X could remove some of the more core components that others may need in their programs, and release it as a package itself.

How much this would gain or save I don't know, but its a possibility to keep from having a vortex of impending deps (I would hate to see a KDE app require gnome-base...)

What is this solution you speak of? You mean rewritting portage, or changing how the packages are added into the system?

[optics]

RPM based systems have had to deal with circular dependencies as well..

I believe they solve it by allowing multiple packages within the same command to satisfy the circular dependency and allow the install. I suppose there is a difference between a compile time dependency and a usage dependency which may not be taken into account right now?

[Dralnu]

RPM based systems have had to deal with circular dependencies as well..

I believe they solve it by allowing multiple packages within the same command to satisfy the circular dependency and allow the install. I suppose there is a difference between a compile time dependency and a usage dependency which may not be taken into account right now?

Well, considering most of us use source for the whole basis of our system, a circular dep for compiling is as bad almost as one needed for runtime. Its an annoying waste of time when you think of it.

Look at it this way (this is an extreme example, btw). If, say, KDE required OOo, and OOo required KDE (say half of KDE needed OOo), then that would mean there would be a MAJOR problem with slower systems. Granted, like I said, this is an extreme example, it has a point...

[yoshi314]

i like some ideas in debian packaging - some packages are split by devs into smaller parts. e.g. glibc and its locales are separate.

gcc is split into separate language packages (c and c++ are separate packages, unless i'm mistaken here).

also many packages are split into binary and dev- packages (which include headers and libtool archives). although this would not be an option for gentoo users, i think :>

if there ever was a way to build e.g. qt without mysql support and then just build the missing mysql support libraries without rebuilding _entire_ qt - it would be truly awesome. same goes for all those long-building packages.

but that would be insanely hard for the devs. just looking at the work put into split-kde ebuilds and eclasses makes it look like an extremely tough task.

[Dralnu]

i like some ideas in debian packaging - some packages are split by devs into smaller parts. e.g. glibc and its locales are separate.

gcc is split into separate language packages (c and c++ are separate packages, unless i'm mistaken here).

also many packages are split into binary and dev- packages (which include headers and libtool archives). although this would not be an option for gentoo users, i think :>

if there ever was a way to build e.g. qt without mysql support and then just build the missing mysql support libraries without rebuilding _entire_ qt - it would be truly awesome. same goes for all those long-building packages.

but that would be insanely hard for the devs. just looking at the work put into split-kde ebuilds and eclasses makes it look like an extremely tough task.

The workload on the gentoo devs would be pretty rough. As for building only the parts that don't need, in your example, mysql support, I think the reason for that is that some of those deps are so wide-spread into the package, its in every src file, and some of the functions that require it are so basic, so needed, that waiting to compile them isn't even an option.

[optics]

there can't be an actual compile time circular dependency with two pieces of software, can there? it just doesn't make sense to me..

if that is the case they are really part of the same package and need to be compiled together as part of one make. On the other hand, if there was a distinction between a requirement for execution vs compile, it should allow portage to get a package and whatever is needed to compile it, and then to get whatever is needed to run it, seperately.. maybe i'm just being a n00b though

[Dralnu]

Deps can get complex quick at times...

[Slippery Jim]

there can't be an actual compile time circular dependency with two pieces of software, can there? it just doesn't make sense to me..

if that is the case they are really part of the same package and need to be compiled together as part of one make. On the other hand, if there was a distinction between a requirement for execution vs compile, it should allow portage to get a package and whatever is needed to compile it, and then to get whatever is needed to run it, seperately.. maybe i'm just being a n00b though

Here's a good example:

Given a USE variable which includes doc, cups, and gnutls:

nasm requires ghostscript (doc)
ghostscript requires cups. (cups)
cups requires gnutls. (gnutls)
gnutls requires lzo (runtime dep)
lzo requires nasm.

Note that while lzo is a runtime dep of gnutls, it is effectively a compile time dep of nasm, because the nasm ebuild needs to use ghostscript utilities to complete successfully.

I hit this on a new install, with 'emerge -evp system'

[ExZombie]

As I see it, it's the same as the bootstrap problem, i.e. you can't build the toolchain without the toolchain. There's just no way around that.
The only thing you can do is to build with basic functionality first, and rebuild again later. Portage could perhaps provide a way to automatically figure out which USE flags cause the circular depends, and temporarily disable them, build the offending packages and then rebuild them with USE enabled. But implementing that would probably cause even more problems before it would mature enough.

[Carlo]

one : USE="gif sdl"
xorg-server -> libsdl -> giflib -> xorg-server

Apparently only in case USE=kdrive, so most users shouldn't run into this.

giflib, even with "-X" use flag wants X via its deps somehow. i had to remove USE="gif" and i will have to rebuild libsdl later.

Its dependency media-libs/urt has a X use flag as well. More "interesting" is that urt optionally depends on giflib as well.

i wonder what awaits us in the future when more and more open-source software gets integrated with each other. ehh

i guess we will be sentenced to deal with those circular deps...forever :/

Well, there are circular dependencies it cannot be worked around and Portage should at some day deal with this transparently and there are others we can work around by splitting packages like it has been done with poppler and poppler-bindings or qt and qt-unixODBC. What really is needed is that you file a bug for each of the circular dependencies you notice, so we can track and fix the issues.