| View previous topic :: View next topic |
| Author |
Message |
Thargor
Apprentice
Joined: 23 Dec 2005
Posts: 239
Location: Bamberg/Germany
|
 Posted: Thu Jun 26, 2008 4:06 pm Post subject: |
 |
|
I think -s isn't needed, since it seems to only have an effect, when you use qlist to list the CONTENTS of a package
_________________
Ideas are bulletproof |
|
| Back to top |
|
 |
Thargor
Apprentice
Joined: 23 Dec 2005
Posts: 239
Location: Bamberg/Germany
|
| Posted: Sat Jun 28, 2008 11:58 am Post subject: |
|
|
portage trunk just got a new feature, that will be in _rc2:
The --keep-going option. With this option, emerge tries to continue when a package fails, but drops all packages with unsatisfied dependencies.
Example: | Code: | [ebuild N ] app-misc/foo-1
[ebuild N ] app-misc/bar-2
[ebuild N ] app-misc/baz-1.5 |
Let's assume bar-2 fails --> foo-1 cannot be emerged, but emerge will install baz-1.5, because none of it's deps failed.
Note that --skipfirst also works that way now. So if you use emerge --resume --skipfirst in the case above after it failed (without --keep-going), it will refuse to install foo-1. To restore the old behaviour, use --resume --skipfirst --nodeps
I'll also add this to my previous post to keep the information in one place
_________________
Ideas are bulletproof |
|
| Back to top |
|
|
Bloodsurfer
Guru
Joined: 07 Dec 2005
Posts: 359
Location: Germany (Saarland)
|
| Posted: Sat Jun 28, 2008 12:41 pm Post subject: |
|
|
| Thargor wrote: | portage trunk just got a new feature, that will be in _rc2:
The --keep-going option. With this option, emerge tries to continue when a package fails, but drops all packages with unsatisfied dependencies. |
YAY! That is one feature I have been missing since forever. 
And thanks for that tipp with -C for qlist, I just found out too late that my solution didn't work at all without that switch 
_________________
SiberianSniper: my girlfriend's name ends with .c
Clete2: Uber geek! W00t! I'd rather have it end in .cpp... <insert name>.cpp
Dralnu: ...why not <name>.o? Then she's ready for linking...
SiberianSniper: or <name>.ko, so she's ready for insertion? |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 8690
Location: beyond the rim
|
|
| Back to top |
|
|
Thargor
Apprentice
Joined: 23 Dec 2005
Posts: 239
Location: Bamberg/Germany
|
| Posted: Sun Jun 29, 2008 9:50 am Post subject: |
|
|
Thanks genone, also added that to my previous post
_________________
Ideas are bulletproof |
|
| Back to top |
|
|
kernelOfTruth
Watchman
Joined: 20 Dec 2005
Posts: 5345
Location: Vienna, Austria; Germany; hello world :)
|
| Posted: Mon Jun 30, 2008 4:34 pm Post subject: |
|
|
| Bloodsurfer wrote: | | Thargor wrote: | portage trunk just got a new feature, that will be in _rc2:
The --keep-going option. With this option, emerge tries to continue when a package fails, but drops all packages with unsatisfied dependencies. |
YAY! That is one feature I have been missing since forever.
[snip] ... [snip] |
++
the world has been waiting for this feature for sooooo long
_________________
Unofficial minimal livecd x86/amd64 w/reiser4+truecrypt (by Neo2)
2.6.37.2_plus_v1: BFS, CFS,THP,compaction, zcache or TOI
Hardcore Linux user since 2004 |
|
| Back to top |
|
|
Sir Link
Tux's lil' helper
Joined: 02 Feb 2008
Posts: 146
Location: /dev/chair
|
| Posted: Wed Jul 02, 2008 6:55 am Post subject: |
|
|
Some questions:
-Any status on when rc2 will be in the tree?
-Any estimates on how stable rc1 is right now on amd64?
-Any ideas whether rc2 will have the same stability when it hits the tree?
The new features look great, and I'm eager to try them out, but I won't upgrade if there's a good change of screwing up my system (hence why I haven't upgraded to openrc/baselayout 2). From the above, it also seems that rc2 will be quite a bit better than rc1.
_________________
Allahu snackbar! |
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Wed Jul 02, 2008 8:13 am Post subject: |
|
|
Thanks for all this great info!
After reading the upgrade guide, one thing is slightly unclear. How does the preserve-libs feature differ from slots? I thought slots were supposed to keep different versions of the same thing on the system. |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 2590
|
| Posted: Wed Jul 02, 2008 5:21 pm Post subject: |
|
|
| node_one wrote: | | How does the preserve-libs feature differ from slots? |
It is meant for libraries which are not supposed to be slotted: Typically, you will of course want to keep the number of libraries on your system as small as possible, that's why most libraries are not slotted (except where it is unavoidable), i.e. if you build a package against the library only the newest will be used, and the older ones are unnecessary. However, the installed packages (which had previously been built against the previous version of the library) still need the older one, but once they are re-emerged they don't need it either. So the old library has to be kept temporarily until all packages using it have been reemerged (otherwise the installed programs will break). The latter is usually done with revdep-rebuild. |
|
| Back to top |
|
|
arnvidr
Guru
Joined: 19 Aug 2004
Posts: 441
Location: Oslo, Norway
|
| Posted: Wed Jul 02, 2008 10:05 pm Post subject: |
|
|
| Sir Link wrote: | Some questions:
-Any status on when rc2 will be in the tree?
-Any estimates on how stable rc1 is right now on amd64?
-Any ideas whether rc2 will have the same stability when it hits the tree?
The new features look great, and I'm eager to try them out, but I won't upgrade if there's a good change of screwing up my system (hence why I haven't upgraded to openrc/baselayout 2). From the above, it also seems that rc2 will be quite a bit better than rc1. |
Running rc1 on amd64 now, have had no issues. Also upgraded to baselayout2 last week, and so far, absolutely no problems, just follow the guide on migrating your configuration files.
_________________
|
|
| Back to top |
|
|
node_one
Apprentice
Joined: 07 Apr 2008
Posts: 165
|
| Posted: Wed Jul 02, 2008 10:33 pm Post subject: |
|
|
| mv wrote: | | node_one wrote: | | How does the preserve-libs feature differ from slots? |
It is meant for libraries which are not supposed to be slotted: Typically, you will of course want to keep the number of libraries on your system as small as possible, that's why most libraries are not slotted (except where it is unavoidable), i.e. if you build a package against the library only the newest will be used, and the older ones are unnecessary. However, the installed packages (which had previously been built against the previous version of the library) still need the older one, but once they are re-emerged they don't need it either. So the old library has to be kept temporarily until all packages using it have been reemerged (otherwise the installed programs will break). The latter is usually done with revdep-rebuild. |
Interesting. I am sure the developers are doing their best, but is there a possibility that portage might mis-track these extra libs and forget to remove them later? In that case, isn't the older behavior of breaking stuff and running revdep-rebuild "cleaner", at least for now? |
|
| Back to top |
|
|
mv
Advocate
Joined: 20 Apr 2005
Posts: 2590
|
| Posted: Thu Jul 03, 2008 6:55 am Post subject: |
|
|
| node_one wrote: | | but is there a possibility that portage might mis-track these extra libs and forget to remove them later? In that case, isn't the older behavior of breaking stuff and running revdep-rebuild "cleaner", at least for now? |
This is not the only problem: Just think of the case that library A has been upgraded and you have packages B and C using different versions of A. Now a package using libraries from B and C can show all sorts of funny behavior.
The two mentioned problems are the reason that the first thing I did after upgrading was putting FEATURES=-preserve-libs into my /etc/make.conf. IMHO it is a misconception, but many people have asked for it. |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 8690
Location: beyond the rim
|
| Posted: Thu Jul 03, 2008 9:17 am Post subject: |
|
|
| node_one wrote: | | Interesting. I am sure the developers are doing their best, but is there a possibility that portage might mis-track these extra libs and forget to remove them later? In that case, isn't the older behavior of breaking stuff and running revdep-rebuild "cleaner", at least for now? |
Well, in theory anything can go wrong. But currently the registration for these libs is only removed when the file doesn't exist anymore (either because portage removed it automatically, or the package was unmerged, or you manually deleted/renamed the file). |
|
| Back to top |
|
|
Sir Link
Tux's lil' helper
Joined: 02 Feb 2008
Posts: 146
Location: /dev/chair
|
| Posted: Sat Jul 26, 2008 10:57 pm Post subject: |
|
|
I've just upgraded to 2.2_rc3, and apparently, it doesn't have @all-installed like Genone's doc said; | Code: |
# emerge -vp1 @all-installed
emerge: there are no sets to satisfy all-installed.
|
Am I missing something here? (I haven't been feeling too sane today, so forgive me if I have missed something simple.)
_________________
Allahu snackbar! |
|
| Back to top |
|
|
myceliv
Apprentice
Joined: 29 Nov 2007
Posts: 178
|
| Posted: Sun Jul 27, 2008 12:26 am Post subject: |
|
|
| Sir Link wrote: | I've just upgraded to 2.2_rc3, and apparently, it doesn't have @all-installed like Genone's doc said;
|
It looks like it is 'emerge @installed' instead, (peeking into /usr/share/portage/config/sets.conf on portage-2.2_rc3) |
|
| Back to top |
|
|
Genone
Retired Dev
Joined: 14 Mar 2003
Posts: 8690
Location: beyond the rim
|
| Posted: Sun Jul 27, 2008 1:40 am Post subject: |
|
|
| Sir Link wrote: | I've just upgraded to 2.2_rc3, and apparently, it doesn't have @all-installed like Genone's doc said; | Code: |
# emerge -vp1 @all-installed
emerge: there are no sets to satisfy all-installed.
|
Am I missing something here? (I haven't been feeling too sane today, so forgive me if I have missed something simple.) |
That's why it's still a draft (the name changed from @everything in rc1 to @all-installed when I wrote the doc and later to @installed in rc2). |
|
| Back to top |
|
|
Sir Link
Tux's lil' helper
Joined: 02 Feb 2008
Posts: 146
Location: /dev/chair
|
| Posted: Sun Jul 27, 2008 6:26 am Post subject: |
|
|
Thanks. That fixes it.
I'm liking 2.2 so far . Good job, devs!
e: Thargor/arnvidr, loving that @live set.
_________________
Allahu snackbar! |
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5609
Location: Dallas
|
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5609
Location: Dallas
|
|
| Back to top |
|
|
transpetaflops
Tux's lil' helper
Joined: 16 May 2005
Posts: 102
|
| Posted: Sun Oct 26, 2008 9:08 pm Post subject: |
|
|
| So, what is the difference between the package sets "system" + "world" and "installed"? I was under the impression that "world" was everything. |
|
| Back to top |
|
|
pappy_mcfae
Watchman
Joined: 27 Dec 2007
Posts: 5609
Location: Dallas
|
| Posted: Sun Oct 26, 2008 9:23 pm Post subject: |
|
|
The only difference I've seen in emerge -aev world and emerge -aev @installed is the order in which things get compiled. Now, that could be a matter of perception on my part, as it seems that the emerge -aev world more or less followed the pattern of how things were emerged as the system evolved to what it is, while emerge @installed seemed to work in alphabetical order. The final result is the same for using either world or @installed: a full recompile.
Blessed be!
Pappy
_________________
SITE LIST:
Main: http://www.kernel-seeds.org
Mirror: http://kernel-seeds.bloodnoc.org/
Mirror 2: http://kernel-seeds.audiodef.com/
Mirror 3: http://www.elilabs.com/~pappy/ |
|
| Back to top |
|
|
|
Portage & Programming
