[gentoo-user] utempter vs libutempter
When doing an emerge --tree --ask --verbose --newuse --update --deep world I received the following error These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [blocks B ] sys-apps/utempter (is blocking sys-libs/libutempter-1.1.2.1) [ebuild U ] x11-terms/xterm-207-r1 [207] -Xaw3d +doc -toolbar +truetype +unicode 727 kB [ebuild N] sys-libs/libutempter-1.1.2.1 21 kB Total size of downloads: 749 kB !!! Error: The above package list contains packages which cannot be installed !!!on the same system. I *thought* I knew what to do when such a blockage occurs. I 1. did a quickpge utempter (for safety) 2. unmerged utempter 3. emerged libutempter 4. re-emerged utempter (from the portage tree not /usr/portage/packages) No errors were reported during any of these 4 steps. But now an emerge world reports Calculating world dependencies ...done! [blocks B ] sys-apps/utempter (is blocking sys-libs/libutempter-1.1.2.1) [nomerge ] x11-terms/xterm-207-r1 -Xaw3d +doc -toolbar +truetype +unicode [nomerge ] sys-libs/libutempter-1.1.2.1 Total size of downloads: 0 kB !!! Error: The above package list contains packages which cannot be installed !!!on the same system. Reading the ebuilds I can see the problem. * both: PROVIDE=virtual/utempter * libutempter demands exclusivity: DEPEND=!virtual/utempter So they really do block. Which one am I supposed to keep and which one should I unmerge ... ... and how should I have figured this out? What is the correct procedure when a blockage is encountered? Should I write a wiki page with this information? thanks, allan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
There was a blog entry on planet gentoo recently about this: http://planet.gentoo.org/developers/seemant/2006/06/02/utemptations_with_xterm It looks like you have to unmerge utempter and then emerge libutempter and rebuild xterm. On Saturday, 3 June 2006 22:48, Allan Gottlieb wrote: When doing an emerge --tree --ask --verbose --newuse --update --deep world I received the following error These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [blocks B ] sys-apps/utempter (is blocking sys-libs/libutempter-1.1.2.1) [ebuild U ] x11-terms/xterm-207-r1 [207] -Xaw3d +doc -toolbar +truetype +unicode 727 kB [ebuild N] sys-libs/libutempter-1.1.2.1 21 kB Total size of downloads: 749 kB !!! Error: The above package list contains packages which cannot be installed !!!on the same system. I *thought* I knew what to do when such a blockage occurs. I 1. did a quickpge utempter (for safety) 2. unmerged utempter 3. emerged libutempter 4. re-emerged utempter (from the portage tree not /usr/portage/packages) No errors were reported during any of these 4 steps. But now an emerge world reports Calculating world dependencies ...done! [blocks B ] sys-apps/utempter (is blocking sys-libs/libutempter-1.1.2.1) [nomerge ] x11-terms/xterm-207-r1 -Xaw3d +doc -toolbar +truetype +unicode [nomerge ] sys-libs/libutempter-1.1.2.1 Total size of downloads: 0 kB !!! Error: The above package list contains packages which cannot be installed !!!on the same system. Reading the ebuilds I can see the problem. * both: PROVIDE=virtual/utempter * libutempter demands exclusivity: DEPEND=!virtual/utempter So they really do block. Which one am I supposed to keep and which one should I unmerge ... ... and how should I have figured this out? What is the correct procedure when a blockage is encountered? Should I write a wiki page with this information? thanks, allan -- Raymond Lewis Rebbeck -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
At Sat, 03 Jun 2006 22:56:21 +0930 Raymond Lewis Rebbeck [EMAIL PROTECTED] wrote: On Saturday, 3 June 2006 22:48, Allan Gottlieb wrote: When doing an emerge --tree --ask --verbose --newuse --update --deep world I received the following error These are the packages that I would merge, in reverse order: Calculating world dependencies ...done! [blocks B ] sys-apps/utempter (is blocking sys-libs/libutempter-1.1.2.1) [ebuild U ] x11-terms/xterm-207-r1 [207] -Xaw3d +doc -toolbar +truetype +unicode 727 kB [ebuild N] sys-libs/libutempter-1.1.2.1 21 kB Total size of downloads: 749 kB !!! Error: The above package list contains packages which cannot be installed !!!on the same system. I *thought* I knew what to do when such a blockage occurs. I 1. did a quickpge utempter (for safety) 2. unmerged utempter 3. emerged libutempter 4. re-emerged utempter (from the portage tree not /usr/portage/packages) No errors were reported during any of these 4 steps. But now an emerge world reports Calculating world dependencies ...done! [blocks B ] sys-apps/utempter (is blocking sys-libs/libutempter-1.1.2.1) [nomerge ] x11-terms/xterm-207-r1 -Xaw3d +doc -toolbar +truetype +unicode [nomerge ] sys-libs/libutempter-1.1.2.1 Total size of downloads: 0 kB !!! Error: The above package list contains packages which cannot be installed !!!on the same system. Reading the ebuilds I can see the problem. * both: PROVIDE=virtual/utempter * libutempter demands exclusivity: DEPEND=!virtual/utempter So they really do block. Which one am I supposed to keep and which one should I unmerge ... ... and how should I have figured this out? What is the correct procedure when a blockage is encountered? Should I write a wiki page with this information? thanks, allan There was a blog entry on planet gentoo recently about this: http://planet.gentoo.org/developers/seemant/2006/06/02/utemptations_with_xterm It looks like you have to unmerge utempter and then emerge libutempter and rebuild xterm. -- Raymond Lewis Rebbeck Thanks for the pointer. It is just what I needed. (I reorganized your response into bottom-posting style, which I believe is the convention for this group). So this utmpter/libutmpter appears to be a special case where the normal unmerge A merge B merge A is wrong. thanks again, allan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
On Saturday, 3 June 2006 23:24, Allan Gottlieb wrote: So this utmpter/libutmpter appears to be a special case where the normal unmerge A merge B merge A is wrong. thanks again, allan I don't believe the procedure you mentioned has ever been normal. If packages block it usually indicates that a package is being replaced by another. An example is how shadow recently replaced pam-login. -- Raymond Lewis Rebbeck -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
At Sat, 03 Jun 2006 23:46:48 +0930 Raymond Lewis Rebbeck [EMAIL PROTECTED] wrote: On Saturday, 3 June 2006 23:24, Allan Gottlieb wrote: So this utmpter/libutmpter appears to be a special case where the normal unmerge A merge B merge A is wrong. thanks again, allan I don't believe the procedure you mentioned has ever been normal. If packages block it usually indicates that a package is being replaced by another. An example is how shadow recently replaced pam-login. Normal was a poor word choice. It is sometimes done. For example when I googled packages which cannot be installed on the first page I found GENTOO Tips When updating your system, the following error may occur: Error: The above package list contains packages which cannot be installed on the same system. ... ww2.cs.fsu.edu/~stanovic/gentoo.html - 3k - Cached - Similar pages Following the link gave When updating your system, the following error may occur: Error: The above package list contains packages which cannot be installed on the same system. * In order to overcome this error, it is probably best to first run emerge with the --ask argument. This will give you the package that wishes to be installed and the package that is blocking it. First unmerge the blocking package, then emerge the package that wished to be installed. Finally emerge the package that you initially unmerged. I would think that the idea is that merging B (which is new or updated) changed the system so that A can now be remerged. For example perhaps the updated B has changed DEPEND and/or PROVIDE. allan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
I would think that the idea is that merging B (which is new or updated) changed the system so that A can now be remerged. For example perhaps the updated B has changed DEPEND and/or PROVIDE. This makes sense (despite 1.5 years of Gentoo I still don't get all subtle Portage features...my fault). Thanks! m. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
b.n. wrote: I would think that the idea is that merging B (which is new or updated) changed the system so that A can now be remerged. For example perhaps the updated B has changed DEPEND and/or PROVIDE. This makes sense (despite 1.5 years of Gentoo I still don't get all subtle Portage features...my fault). Thanks! m. Don't fell bad. Every time I think I get something, they change it. I was just getting used to etcat and then they took it away in favor of equery which confuses me. Someone told me where they hid etcat though. ;-) Dale :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
Allan Gottlieb wrote: unmerge A merge B merge A When A is blocking B, the normal thing to do is to just unmerge A, and then execute again the command that reported the blockage. This is normally something like 'emerge -vaDu world'. If the package you unmerged is still needed, it will then automatically get remerged. Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
At Sat, 03 Jun 2006 22:20:25 +0200 Benno Schulenberg [EMAIL PROTECTED] wrote: Allan Gottlieb wrote: unmerge A merge B merge A When A is blocking B, the normal thing to do is to just unmerge A, and then execute again the command that reported the blockage. This is normally something like 'emerge -vaDu world'. If the package you unmerged is still needed, it will then automatically get remerged. I see. This would cover many cases. But the command original command could have been emerge (perhaps --update) B. A might still be needed (e.g. it might have been in world). With (the updated) B merged an emerge of A could still be successful since the ebuild for A might behave differently with (the updated) B present. Another example would be the original command was 'emerge -vaDu world', but A was in world and is not depended upon by anything else. Since A was unmerged, it will not be remerged. I don't know if this occurs in practice. These examples are admittedly rather comtrived. My google search result (posted a few msgs ago) gave the three step sequence you quoted above. I agree that your proposed two step procedure is more likely to give better results. Is the following modification of yours better or worse. It does seem to cover an extra case, but may be too complicated to put in a wiki page When A is blocking B, the normal thing to do is to unmerge A, and then execute again the command that reported the blockage. This command is normally something like 'emerge -vaDu world'. If the package you unmerged is still needed, it will often automatically get remerged. However, if A was originally in world and not depended upon by anything else, it will not be remerged. If A is still needed it must be explicitly emerged. (With the, possibly updated, B now merged the ebuild of A may behave differently so that no blockage occurs.) allan -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
Allan Gottlieb wrote: These examples are admittedly rather comtrived. My google search result (posted a few msgs ago) gave the three step sequence you quoted above. When googling for advice, you may want to include site:gentoo.org in your terms, and maybe even handbook. Searching for 'blocking site:gentoo.org handbook' gives a link to a Portage Introduction and one to a Quick Install Guide that although very terse are together clear enough, in my opinion. However, if A was originally in world and not depended upon by anything else, it will not be remerged. If A is still needed If A was in world, it was by definition not needed. Sure, the user wanted the package, but that is something else. :) it must be explicitly emerged. No need to tell the user that: she will remember which packages she wants to have installed. Benno -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] utempter vs libutempter
At Sun, 04 Jun 2006 00:07:44 +0200 Benno Schulenberg [EMAIL PROTECTED] wrote: Allan Gottlieb wrote: These examples are admittedly rather comtrived. My google search result (posted a few msgs ago) gave the three step sequence you quoted above. When googling for advice, you may want to include site:gentoo.org in your terms, and maybe even handbook. Terrific suggestion. Thanks. Searching for 'blocking site:gentoo.org handbook' gives a link to a Portage Introduction and one to a Quick Install Guide that although very terse are together clear enough, in my opinion. However, if A was originally in world and not depended upon by anything else, it will not be remerged. If A is still needed If A was in world, it was by definition not needed. Sure, the user wanted the package, but that is something else. :) Cute. Not relevant, but indeed cute. -:) it must be explicitly emerged. No need to tell the user that: she will remember which packages she wants to have installed. A rather optimistic assumption. One might have originally emerged A quite a *long* time ago. Nonetheless, I must agree that your procedure will work nearly all the time, and the extra coverage I offered may well be offset by the extra complexity of the wording, which is not needed in nearly all cases. allan -- gentoo-user@gentoo.org mailing list
