emerge --pretend --deep -u world wants to install xterm. I use gnome-terminal and so have no need of classic xterm. I noticed that xorg-x11 has a PDEPEND on xterm. I don't know exactly how PDEPEND is different from RDEPEND, but my system runs fine without xterm, so it's obviously not needed. I edited the xorg-x11 ebuild file myself and ran emerge metadata, and xterm no longer shows up as something to be installed, but that goes away as soon as I do another sync. Between the xorg.x11 changelog and bugs.g.o, it looks like bug 47100 is where that PDEPEND entry was made. Reproducible: Always Steps to Reproduce: emerge --pretend --deep -u world Actual Results: These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild N ] x11-terms/xterm-197 Expected Results: These are the packages that I would merge, in order: Calculating world dependencies ...done!
Sorry, it's currently part of X.Org's distributed X11 implementation, so we put it out. You would normally get it anyway by building X from source -- we just set it up to build independently so you don't need to upgrade all of xorg to get an xterm fix. I'm looking into creating a virtual/term in the future, but it hasn't happened yet.
Is there any reason to have a PDEPEND on any terminal program *at all*? This doesn't apply directly to me, as I'm a command-line junkie like many Gentoo users. However, what about the people out there who don't want to ever have to touch a command line? If the GNOME and KDE folks do what they're setting out to do, it should be possible to have a fully working system without any need for command-line interaction. If I ever convince Mom, a current WinME user, to try Gentoo, I'd show her the nice GNOME desktop with gdm, and I might not even want to have any terminal program around, to save space and {download,compile} time. I noticed that today, though not when the dependency was first added, the PDEPEND only applies if the system doesn't have uclibc, presumably for kiosks and such. If those users, while welcome to install a term, don't actually *need* one, why do ordinary desktop users "need" one? For me, and probably for most current Gentoo users, the suggested virtual/term works fine, and is certainly better than the current configuration. However, as the Installation section of the x86 Handbook states: "It is very important that you understand that choices are what makes Gentoo run. We try not to force you onto anything you don't like. If you feel like we do, please bugreport it." So here I am :). (That's not to say that virtual/term is a good idea for any programs that do happen to *need* an X terminal emulator program; even having it around just so that future packages can use it, instead of hard-coding x11-terms/xterm, is a good design choice IMHO. I just question whether xorg-x11 needs any such dependency.)
The uclibc is there because utempter, which xterm uses, is currently broken on uclibc. xterm is installed because a standard X installation is _expected_ to have xterm. In the future, we plan to "extend" this by saying rather than _xterm_, _a term_.
Well, how about a USE flag for those of us who might want to leave it out anyway?
Hi, Jason. I'm just another user but follow the gentoo-dev list and saw Donnie working to coordinate the switch to virtual/term, there. He referenced this bug, and having similar issues myself, I've got a couple suggestions that should make things a bit easier for you until the change is completed. There are actually two current "Gentoo way" methods of coping with this, without having your changes overwritten at each sync. Knowing them will provide you with greater flexibility with other problems as well, so it's worth noting them even if virtual/term is on the way. First, take a look at "Working with Portage" (part three) in the Gentoo Handbook. Section 1a, Files and Directories, Portage Files, then subsection User-Specific Configuration, mentions the optional files in /etc/portage. In particular for this issue, you want package.mask. Here, I listed x11-terms/xterm in that file, and portage now knows not to emerge it. Listing the same package in /etc/portage/profile/package.provided tells portage to act as if it's already installed. (This is a replacement for the emerge --inject option, which has been depreciated. This isn't documented in the handbook, yet, altho the portage manpage alludes to the profile subdir.) Second, altho with the above it's no longer necessary, if you ever /do/ want to edit an ebuild, copy it to your overlay (Handbook, part three, section 5b, Diverting from the Official Tree, Adding Unofficial Ebuilds) and make your changes there. That way, they won't be erased every time you emerge sync. See, Gentoo really /does/ provide choice and lots of flexibility, including the ability to skip xterm, even without a specific virtual/term virtual. =8^) Even tho the virtual looks like it will be added, learning these "Gentoo way" methods will increase your options the next time something like this comes up. Duncan
After some discussion, I've come to the conclusion that this is too much hassle for too little benefit.
