| View previous topic :: View next topic |
| Author |
Message |
InfoManiac
n00b
Joined: 23 Jan 2006
Posts: 53
|
 Posted: Sun Mar 18, 2007 9:30 pm Post subject: |
 |
|
| zmedico wrote: | | (API, Javadoc, etc) |
[/quote]
That does not help, what APIs? and Javadoc, you have several version of Java floating around Portage -- "Etc" that doesn't mean anything to me, or is it that no one really know what _specific_ programs install what.
All anyone has done is say what is quoted above, that is not helping.
Why not just at _least_ say "dev" or "non-dev" packages?
This seems to be a norm for Gentoo as whole, everyone wants to say nothing can be done and anything this is doable is impossible.
How does anyone resolve any conflicts with the problems that are had with this distribution? All anyone does is repeat what is said (see quote above) and nothing else, or that the user is just going to have to "deal with it"
This is very frustrating beyond all belief. No questoins ever get answered and there are ultimately no solutions. And anyone who replied only read about a 1/4 of what I said, and didn't actually _answer_ the question.
I'm tossing out ideas and it's like I didn't becuase that isn't addressed either, I jut cannot believe this how does the Gentoo org get _anything_ done or solved? I am asking a serious question that isn't not meant as mal-intent.
This has got to be the most frustrating organization I have ever had to deal with. If what just transpired doesn't happen a fight will break out and no one ends up winning.
Can you understand what I mean, I am sincere in trying to understand this, once again, I mean no mal intent just so you know and hopefully that will stave off anyone thinking I am trying to start something as this is not my intent what-so-ever, by any means.
_________________
GIT-RRRR-DOOOONE! |
|
| Back to top |
|
 |
zmedico
Developer
Joined: 02 Jan 2004
Posts: 352
Location: California USA
|
| Posted: Sun Mar 18, 2007 10:40 pm Post subject: |
|
|
| InfoManiac wrote: | That does not help, what APIs? and Javadoc, you have several version of Java floating around Portage -- "Etc" that doesn't mean anything to me, or is it that no one really know what _specific_ programs install what.
|
Per-package USE flag descriptions are available for some flags in ${PORTDIR}/profiles/use.local.desc. Those can be queried via the equery command (see `equery uses --help`). It appears that you want something more than that though. You can write a GLEP that proposes metadata extensions for conveying additional information about USE flag behavior. The new metadata could be stored in the metadata.xml file that each package is required to have.
_________________
Zac |
|
| Back to top |
|
|
Invizix
n00b
Joined: 14 Sep 2004
Posts: 41
|
| Posted: Mon Mar 19, 2007 4:40 am Post subject: |
|
|
There IS a solution to resolve this Circular Dependencies hoo-hah. You have to emerge a few key ebuilds with the USE="-*" flag and then rebuild them without that flag so they compile using their regular dependencies. As for which ones? I forget... so this kind of makes my post useless. >.<
This is what I did to resolve the issue:
First make a list of every ebuild that want / are marked to do a circular dependency.
Do the following command all on one line USE="-*" emerge <ebuild(s)> && emerge <ebuild(s)> -- <ebuild(s)> means any ebuilds that want to do the Circular Dependencies syndrome.
Doing that resolved most if not all of my circular dependencies shinanigans.
_________________
Linux. Freedom. Power.
Last edited by Invizix on Mon Mar 19, 2007 4:52 am; edited 1 time in total |
|
| Back to top |
|
|
zmedico
Developer
Joined: 02 Jan 2004
Posts: 352
Location: California USA
|
| Posted: Mon Mar 19, 2007 4:51 am Post subject: |
|
|
| Invizix wrote: | | You have to emerge a few key ebuilds with the USE="-*" flag and then rebuild them without that flag so they compile using their regular dependencies. |
That will work, but package.use will give you more fine-grained control. See this example of how toggling a single flag can break a dependency cycle.
_________________
Zac |
|
| Back to top |
|
|
Invizix
n00b
Joined: 14 Sep 2004
Posts: 41
|
| Posted: Mon Mar 19, 2007 4:57 am Post subject: |
|
|
| zmedico wrote: | | Invizix wrote: | | You have to emerge a few key ebuilds with the USE="-*" flag and then rebuild them without that flag so they compile using their regular dependencies. |
That will work, but package.use will give you more fine-grained control. See this example of how toggling a single flag can break a dependency cycle. |
Yes, I know... but that was the only thing that resolved my problems. It was only like 10 ebuilds that I did that with... and then emerged them regularly. It cleared my system right up. No more circular dependencies! 
_________________
Linux. Freedom. Power. |
|
| Back to top |
|
|
InfoManiac
n00b
Joined: 23 Jan 2006
Posts: 53
|
| Posted: Mon Mar 19, 2007 6:36 pm Post subject: |
|
|
Things need to be more straightforward and clear, as it stands now they aren't. Gentoo should not be a pain in the arse to use when such issues arise.
I have a hard time believing that these problems can't be SO hard they are not fixable, if so Gentoo needs an overhaul and it's long over do.
These a**-backwards solutions aren't seen in any other distribution, this is the only one where the problems don't get fixed as compared to just using workarounds.
I have had considerable experience with workarounds the only time to use those is when you are coming up with a long term solution becuase workarounds are short term and in the long run only cause more problems.
\In case you may think otherwise...well...we have a circular dependency problems, documentation must've been written by a developer which is fine, but it's not going to work for the regular user of Gentoo.
This needs to be clean, clear, concise and right to the point. This sort of thing *needs* input from end users of Gentoo (as you are getting now) and we need to keep working towards a resolution.
The most frustrating part, sadly, is this hasn't ever happened, at least from what I can see whenever I rad a topic or post one, I have seen no resolution or work towards one in most threads.
I honestly wish it weren't like this.
This really is a bad thing for the distribution as a whole becuase the problem(s) I am addressing are global and general problems with the core of Gentoo. This isn't some minor bug or annoyance, it just makes Gentoo more annoying to use and a pain. It should not be like this.
_________________
GIT-RRRR-DOOOONE! |
|
| Back to top |
|
|
zmedico
Developer
Joined: 02 Jan 2004
Posts: 352
Location: California USA
|
| Posted: Mon Mar 19, 2007 8:42 pm Post subject: |
|
|
| InfoManiac wrote: | | The most frustrating part, sadly, is this hasn't ever happened, at least from what I can see whenever I rad a topic or post one, I have seen no resolution or work towards one in most threads. |
If you want to address the developer community then it's usually best to do that via bugzilla or the gentoo-dev mailing list.
| InfoManiac wrote: | | This isn't some minor bug or annoyance, it just makes Gentoo more annoying to use and a pain. It should not be like this. |
If you want to see Gentoo improve then the best thing you can do is contribute back to the community somehow. If you feel like your forum posts aren't getting through, then I suggest that you try one of the other channels mentioned above.
_________________
Zac |
|
| Back to top |
|
|
InfoManiac
n00b
Joined: 23 Jan 2006
Posts: 53
|
| Posted: Mon Mar 19, 2007 10:30 pm Post subject: |
|
|
Yeah, ultimately you are right....the best way to fix a problem that no one else will, is to do it yourself.
Well, if I ever get the time to allocate I will. I will mull what it is I want to do.
In the meantime this isn't making sense why such a large part of the existing community that can currently do something about this.....isn't.
Also until I can allocate time I will file bugs, etc. for what good that will do.
_________________
GIT-RRRR-DOOOONE! |
|
| Back to top |
|
|
Vojin Katic
n00b
Joined: 06 May 2007
Posts: 2
|
| Posted: Sun May 06, 2007 6:01 am Post subject: Vojin Katic |
|
|
hard thing
_________________
Vojin Katic |
|
| Back to top |
|
|
zxy
Veteran
Joined: 06 Jan 2006
Posts: 1160
Location: in bed in front of the computer
|
| Posted: Thu Jul 05, 2007 9:17 am Post subject: |
|
|
I hope thic circular-dependency problems will at some point be handled automaticaly.
How it will/should be done, I don't know, as I have not enough knowledge about everything involved.
But in the meantime it would be cool if there was some file/database that would include a list of circ-dep problems with the right order of installation of packages and use flags settings. Or something similar.
The package manager could then at least suggest the possible ways of solving the problem if not solve it itself.
_________________
Nature does not hurry, yet everything is accomplished.
Lao Tzu |
|
| Back to top |
|
|
e_FreshMEAT
n00b
Joined: 19 Jan 2006
Posts: 13
|
| Posted: Wed Jul 25, 2007 1:23 am Post subject: Re: How to break dependency cycles |
|
|
| zmedico wrote: | With versions of portage <2.1.2 there was never really any guarantee that a package's dependencies would actually be installed before the package itself. That issue is fixed in portage-2.1.2 (bug 147766) so that correct merge order is always guaranteed and circular dependencies will be reported if they exist. This circular dependency detection prevents random build errors that could otherwise be caused by unsatisfied dependencies (see bug 147127, for example).
In portage-2.1.2-r9, the circular dependency output is often excessively verbose, making it difficult to discern dependency cycles. See bug 166564 for a patch which eliminates excess noise. This patch will be included in portage-2.1.2-r10.
Generally, dependency cycles can be broken by disabling USE flags. For example, in order to break the following cycle:
app-text/ghostscript-gpl-8.54 -> net-print/cups-1.2.6 -> net-libs/gnutls-1.4.4-r1 -> dev-libs/lzo-2.02-r1 -> dev-lang/nasm-0.98.39-r3 -> app-text/ghostscript-gpl-8.54
Temporarily add the following to /etc/portage/package.use:
| Code: | | =dev-lang/nasm-0.98.39-r3 -doc |
This will break that dependency cycle so that those packages can be built and installed. After those package are installed, remove the above package.use setting and remerge nasm with the doc flag enabled. Future versions of portage will be able to do these steps automatically, but it will require the dependency resolver to be rewritten. |
The first time I met this circular dependence was last year some where I emerge the whole world as empty and since that time I find this cycle involves again and again, one year back I met this particular circular dependence again because of my bad memory that the "doc" useflag involves this problem. Remembering cost some time, but one question came to mind is why this "doc" useflag involved this problem and not solved by portage since last time?
After reading piles of posts on this forum about circular deps, I found that this particular circular dependence (app-text/ghostscript-gpl-8.54 -> net-print/cups-1.2.6 -> net-libs/gnutls-1.4.4-r1 -> dev-libs/lzo-2.02-r1 -> dev-lang/nasm-0.98.39-r3 -> app-text/ghostscript-gpl-8.54) seems to be the most discussed, thus I start wondering this particular problem is because portage or this cycle?
My simple thinking is one of this package in this cycle is asked making its own documentation but in a special format which require using a set of tools to generate this format and that particular package itself is also the one in part of this tool set...
So, does this package need its own doc in fancy other than set of txt files? or why this document need to be generate other than pre-compiled? |
|
| Back to top |
|
|
rgviza
n00b
Joined: 01 Aug 2007
Posts: 30
|
| Posted: Fri Feb 15, 2008 7:28 pm Post subject: |
|
|
| zmedico wrote: | | hielvc wrote: | The easist way is to | Code: | | emerge --oneshot --nodeps cups ghostscript |
|
--nodeps is effectively equivalent to what used to happen before emerge was able to detect circular dependencies. There's no guarantee that a package will build like that without it's dependencies installed. In fact, an ebuild *should* fail to build if one or more dependencies aren't installed as required by current USE settings. If the ebuild succeeds anyway, then it's really a QA problem that should be fixed. --nodeps is a hack. The proper solution is to temporarily disable USE flags in order to break dependency cycles. |
It seems like the best way is to remove the offending flag from USE, get past the offending dependency, install the stuff it needs, then add the flag back and emerge -e world?
If the libs are on the system, but without the codependant support this should work right? They'll be installed, emerge will see the flags and link them to each other. IE, if you want to install kde with support for gnome apps:
USE="kde gnome"
on a new system will cause a circular dep when you go to install kde.
However, if you remove gnome from USE, install kde, then install gnome, then put the flag back and emerge -e it will recompile it all with the cross links.
I am completely new to emerge (3 days in). Let me know if I'm starting to grok this issue or destroying my system in subtle ways 
-Viz |
|
| Back to top |
|
|
rgviza
n00b
Joined: 01 Aug 2007
Posts: 30
|
| Posted: Fri Feb 15, 2008 7:58 pm Post subject: |
|
|
| InfoManiac wrote: | Yeah, ultimately you are right....the best way to fix a problem that no one else will, is to do it yourself.
Well, if I ever get the time to allocate I will. I will mull what it is I want to do.
In the meantime this isn't making sense why such a large part of the existing community that can currently do something about this.....isn't.
Also until I can allocate time I will file bugs, etc. for what good that will do. |
Consider
USE="kde gnome"
Probably the simplest solution is a USE cache file in etc. Basically the user sets up his USE variable, but emerge uses his own cache file, which starts out empty, and adds the same use flags to it that are set in USE, but only after the dependancies are actually compiled.
Each emerge session starts with a bit flag set to 0. If he has to add something to his cache it gets set to 1. Then at the end of the emerge job, if it's set to 1 he knows he needs to recalc things and go back to recompile with the full set of deps in the USE cache. If something's not on the system yet it won't be in the cache so emerge will ignore the dependancy and not use the --with-[whatever]. Then set the flag to 1.
In the above example, on a new system, the cache file is empty. You say "emerge kde". Today this results in a circdep. However with my suggestion, He'd compile kde without gnome support(since cache is empty), then add the kde flag to the cache.
After that if you emerge gnome, it would know kde was installed and link gnome to kde, after checking cache, add the kde links as well as add gnome to the cache. After it's done, his flag is set to 1 so he says "Hey, something got added to my USE cache, emerge -e" or possibly just check the installed packages against whats in the cache and only work the stuff that needs to be recomp'd.
Upon checking he'd see that kde had been compiled without gnome support, and gnome is both in USE and now in the cache, so kde needs to be recompiled with the gnome support flag enabled this time.
This cache would be persistent and add flags as the system grew until finally it had all the flags that USE does and we'd be normalized.
I don't know the inner workings of emerge, but this or something similar would solve the problem. It needs a way to compare what's installed with what's in USE so it can be smarter. Sorry I may be a gentnoob, but I am also a programmer who pays attention to what his packagemanager is doing 
-Viz |
|
| Back to top |
|
|
hkmaly
n00b
Joined: 13 Jul 2006
Posts: 45
|
| Posted: Sun Feb 17, 2008 11:44 am Post subject: |
|
|
| rgviza wrote: |
Each emerge session starts with a bit flag set to 0. If he has to add something to his cache it gets set to 1. Then at the end of the emerge job, if it's set to 1 he knows he needs to recalc things and go back to recompile with the full set of deps in the USE cache. If something's not on the system yet it won't be in the cache so emerge will ignore the dependancy and not use the --with-[whatever]. Then set the flag to 1.
|
You mean that instead of compiling package once, it will be compiled as many times as it has use flags ? (At least in worst case). I don't like that. I would rather solve circular dependency by hand that by emerging tens of packages three-times.
Remember, use flag is not the same as "depend on something conditionally". One use flag can mean dependency on different package for different package. Like doc for example. Or the ldap for example: most programs depends on openldap if ldap USE flag is set, but sudo depends also on perl. So, how exactly does your alghorithm solve fact that you need to re-emerge sudo AFTER you emerge perl ? On the other hand, many packages depends unconditionally on something which other packages depends if some use flag is set. Like most gnome/kde stuff. So, how did your alghorithm knows it can't build that package at all until the gnome USE flag is set ?
Also ... about that "ebuild should break if dependency is not met" ... what about adding option like --no-runtime-deps ? So packages which have unmet dependencies but doesn't really need them until used could be build ... of course, there will be problems like if the circular dependence will really be broken by package which is not working, but better that what --nodeps produces. |
|
| Back to top |
|
|
GNUix
n00b
Joined: 06 Aug 2007
Posts: 35
Location: South Korea
|
| Posted: Thu Sep 04, 2008 10:28 am Post subject: |
|
|
today I ran into my first issue with circular dependencies that was not self inflicted. The solutions for me was pretty simple. I need to install dev-util/git but it complained because dev-perl/module-build needed to be installed, which needed dev-perl/version (wtf) which needed dev-perl/module-build... The solution
| Code: |
emerge --oneshot --nodeps dev-perl/module-build
emerge --oneshot dev-perl/module-build
emerge -av dev-util/git
|
Seemed like a better solution than USE="-*" to me. In any case it worked for me, maybe it will help some of you. |
|
| Back to top |
|
|
kdorf
n00b
Joined: 28 May 2009
Posts: 2
|
| Posted: Mon Jun 01, 2009 2:12 pm Post subject: |
|
|
I'm a new Gentoo user here... got it up and running and my laptop not too long ago. I have to say that I love it except for a few things. One of those is circular dependency problems.
The Wiki helpfully stated that making "doc" a global USE flag causes circular dependencies. Thanks for the info but wtf? Of all things, documentation is one of the biggest causes of circular dependencies? Why does documentation have dependencies at all?! I have a hard time buying that readme.gz depends on some other program than maybe zcat, but that's in the core-utils (I believe).
But that's just docs. I have a hard time believing in general that circular dependencies really exist. There MAY be a few fringe cases where they actually pop up but they are by and large far too common. It's annoying. A lot of them aren't even real circular dependencies as the previous poster has shown with his emerge --oneshot --nodeps. If there's really a dependency, the compile should fail.
Just my $0.02 though. The Gentoo devs have otherwise done a fairly outstanding job with Portage, it just needs a little bit more. =) Keep up the good work, guys. |
|
| Back to top |
|
|
hielvc
Advocate
Joined: 19 Apr 2002
Posts: 2805
Location: Oceanside, Ca
|
| Posted: Mon Jun 01, 2009 6:18 pm Post subject: |
|
|
It is not the docs themselves but the doc tools :liveTex, doc-, gst- . and their depends that make the Devs and user bang their heads.
_________________
An A-Z Index of the Linux BASH command line |
|
| Back to top |
|
|
yngwin
Retired Dev
Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China
|
| Posted: Mon Jun 01, 2009 9:44 pm Post subject: |
|
|
| kdorf wrote: | | The Wiki helpfully stated that making "doc" a global USE flag causes circular dependencies. Thanks for the info but wtf? Of all things, documentation is one of the biggest causes of circular dependencies? Why does documentation have dependencies at all?! I have a hard time buying that readme.gz depends on some other program than maybe zcat, but that's in the core-utils (I believe). |
Simple things like ReadMes are always installed, and not triggered by the doc useflag. The doc useflag is especially used in cases where the documentation needs to be generated. So it will then depend on utilities to parse the documentation source files and transform those into the final format.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Portage & Programming
