| View previous topic :: View next topic |
| Author |
Message |
astronic
n00b
Joined: 16 Aug 2003
Posts: 44
Location: Dortmund, Germany
|
 Posted: Sun Sep 14, 2003 9:27 am Post subject: Portage update behavior |
 |
|
Dear Gentoovians,
I'm running gentoo for about a month now and I'm wondering about the right way to update the system via portage.
My priorities regarding updates are (in order):
1) Minimizing the risk of broken dependencies and non-functional software in the short-term as well as in the long-term view.
2) Keeping all packages as up-to-date as possible without compromising point 1.
Obviously I'm not interested in masked ebuilds at all. 
According to the man page of emerge the -D parameter checks recursively the dependencies of the dependencies (of the...) of a package, while emerge -u without the -D parameter only looks for the immediate dependencies of the package to update. As far as I understand doing 'emerge -u world' without -D is a very risky thing to do, since deeper dependencies may not be fulfilled. On the other hand 'emerge -u world' seems to be the standard behavior for upgrading, so I seem to miss the entire point here.
And what happens in the case of a version conflict? Let's say package 'foo' requires package 'libabc' in version 1.0 (and doesn't run with 1.1). Package 'bar' requires 'libabc' in a version greater than 1.1. The ebuild maintainer of 'libabc' doesn't know about this problem and therefore 'libabc' is not sloted, i.e. version 1.0 and 1.1 of 'libabc' can't exist at the same time. Is there a conflict detection like in debian's apt-get which tells the user that I can install either 'foo' or 'bar'? Or will I end up with a non-functional 'foo' or 'bar' package?
The next thing is, when does portage add an ebuild to the world profile?
I was very surprised when I figured that an 'emerge -pu world' didn't want to upgrade my mysql from 4.0.13-r3 to 4.0.13-r4. This can only mean, that mysql is not in my world profile. My only explanation for this is, that mysql was installed as dependency of some other ebuild and that ebuilds not installed directly are not added to the world profile automatically (and I see no reason for this behavior).
However, I also wondered why 'emerge -puD' wanted to trigger an update of mysql, since I can't imagine a package which dependencies are not fulfilled with 4.0.13-r3 but are with 4.0.13-r4. Here my only guess is that '-uD' not only checks if all dependencies are fulfilled but also checks if a newer version of a dependency is available.
At the end I'm a bit unhappy, since I don't trust a package manager which surprises me with it's update behavior. So I'd be very grateful if anyone could clarify these things. I'd also like to take a closer look at my world profile, so if anyone knows where it is located (in the file system), please let me know.
TIA,
Stefan |
|
| Back to top |
|
 |
Netpilgrim
n00b
Joined: 14 Sep 2003
Posts: 2
Location: Germany
|
| Posted: Sun Sep 14, 2003 11:12 am Post subject: |
|
|
Hi!
Some answers regarding your questions about the world profile can be found in the Portage Manual:
| Quote: | | Packages that are manually installed by the user through use of the emerge command are recorded in the world file located at /var/cache/edb/world. |
HTH
Netpilgrim |
|
| Back to top |
|
|
TGL
Bodhisattva
Joined: 02 Jun 2002
Posts: 1978
Location: Rennes, France
|
| Posted: Sun Sep 14, 2003 10:31 pm Post subject: Re: Portage update behavior |
|
|
| astronic wrote: | | According to the man page of emerge the -D parameter checks recursively the dependencies of the dependencies (of the...) of a package, while emerge -u without the -D parameter only looks for the immediate dependencies of the package to update. As far as I understand doing 'emerge -u world' without -D is a very risky thing to do, since deeper dependencies may not be fulfilled. On the other hand 'emerge -u world' seems to be the standard behavior for upgrading, so I seem to miss the entire point here. |
Add this axiom: whem portage emerge something, it always checks its dependency and emerge them first if needed.
Now, assume that you have (where arrows mean "depends on")...
- installed: A-1.0 --> B-1.0 --> C-1.0
- new in tree: A-1.1, B-1.1 with a new dependency on D-1.1, and C-1.1.
After a "-u world", you'll have installed: A-1.1, B-1.1, D-1.1 and C-1.0, because the B update needs D-1.1.
And after a "-uD world", you'll have installed: A-1.1, B-1.1, D-1.1 and C-1.1, for the same reason plus the "deep" which makes portage also applies the update to all dep recursively.
| astronic wrote: | | And what happens in the case of a version conflict? Let's say package 'foo' requires package 'libabc' in version 1.0 (and doesn't run with 1.1). Package 'bar' requires 'libabc' in a version greater than 1.1. The ebuild maintainer of 'libabc' doesn't know about this problem and therefore 'libabc' is not sloted, i.e. version 1.0 and 1.1 of 'libabc' can't exist at the same time. Is there a conflict detection like in debian's apt-get which tells the user that I can install either 'foo' or 'bar'? Or will I end up with a non-functional 'foo' or 'bar' package? |
Portage Doesn't check reverse dependencies, hence this is possible, from the package manager point of view. But this can of possible issues is in general solved at packages level. If there are some packages that really need the lib in version 1.0 and others in version 1.1, then packagers will slot this libs. Also, sometimes it may be really impossible to slot then, and in that case, no miracle, packages really are incompatible, and then there are marked as it in dependencies ("!foo/bar"). And when you see a package broken because of the update of something else, then report it as a bug. One of the above described measure will very likely be taken to fix it.
Now, should portage deal with reverse deps? That's an often seen discussion. Conclusion is in general that sure, it may be interresting, but it would be a lot of work (the portage case is more difficult than for apt-get because of USE flags which introduce conditional dependencies, etc.). Until now, things works pretty well like they are, so this can wait... Maybe in a future complete rewrite of portage we'll have this feature, but there is no urgency.
| astronic wrote: | | The next thing is, when does portage add an ebuild to the world profile? |
This one is already answered.
| astronic wrote: | | I was very surprised when I figured that an 'emerge -pu world' didn't want to upgrade my mysql from 4.0.13-r3 to 4.0.13-r4. This can only mean, that mysql is not in my world profile. My only explanation for this is, that mysql was installed as dependency of some other ebuild and that ebuilds not installed directly are not added to the world profile automatically (and I see no reason for this behavior). |
The world file is here to reflect your intention. It states what you, from a user point of view, want to be installed on your machine. For instance, you may want to install foo-1.0 which depends on bar-1.0. Then foo will be added to your world file, but not bar. If at some point you think foo sucks and you remove it, and bar is no more a dependency of anything, then bar will be unmerge by "depclean". That's what world file is made for.
| astronic wrote: | | However, I also wondered why 'emerge -puD' wanted to trigger an update of mysql, since I can't imagine a package which dependencies are not fulfilled with 4.0.13-r3 but are with 4.0.13-r4. |
The -uD is deep update, for people who want to have everything as up to date as possible.
| astronic wrote: | | Here my only guess is that '-uD' not only checks if all dependencies are fulfilled but also checks if a newer version of a dependency is available. |
Dependencies should always be fulfilled, you are not supposed to play removing random libs on your system if you don't now what you are doing. If you did, then there is no portage-only way to repare it, but it's not a big issue neither. For instance, something like this should give you the packages to install:
| Code: | | emerge -p `for p in $( qpkg -I -v -nc ); do echo =$p` | grep "ebuild N" |
(for all installed packages, do an "emerge -p", and if they have unsatisfied dependencies, then the package to install will appear as new)
| astronic wrote: | | At the end I'm a bit unhappy, since I don't trust a package manager which surprises me with it's update behavior. |
Learn it, read the doc. It's very deterministic, and unexpected behaviors are only wrong comprehension from users |
|
| 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
