app-misc/screen links against utempter if it's available during compilation, but does not depend on it. So if utempter was installed by some other package that now got removed, screen is unusable after "emerge depclean". Reproducible: Always Steps to Reproduce: 1. emerge --oneshot utempter 2. emerge screen 3. emerge depclean 4. screen -ls Actual Results: copper root # screen -ls screen: error while loading shared libraries: libutempter.so.0: cannot open shared object file: No such file or directory copper root # Expected Results: Create a new (local?) USE flag "utempter" to control both the dependancy on and the use of utempter. Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.3.4, glibc-2.3.4.20040808-r1, 2.6.9-copper-1 i686) ================================================================= System uname: 2.6.9-copper-1 i686 AMD Athlon(tm) processor Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.90.0.1.1-r3 Headers: sys-kernel/linux-headers-2.4.21-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox sfperms" GENTOO_MIRRORS="ftp://ftp.easynet.nl/mirror/gentoo/ http://gentoo.inode.at/ ftp://gentoo.inode.at/source/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/inst/level3/sync/portage-local" SYNC="rsync://hybrid.sascha.silbe.org/gentoo-portage" USE="acl berkdb bitmap-fonts crypt doc f77 fortran gdbm ipv6 jpeg maildir mbox ncurses nls oggvorbis pam png python readline ssl unicode x86 xml xml2 zlib linguas_en_US linguas_en_GB linguas_en linguas_de_DE linguas_de"
i'm pretty sure that it doesnt require it, but screen has optional checks and will enable support for it if found
Screen doesn't require utempter. We set screen setgid utmp to allow screen to update utmp records itself and don't use a helper to do it. I'm currently thinking if it would be safer to use utempter and remove the setgid bit from screen.
please dont, utempter doesnt work in uclibc env's see Bug 69470
I removed the utempter check from configure. Revision bumped to distribute this fix. Thanks for reporting!
Would it be possible to make the usage of utempter/libutempter conditional by introducing a local utempter useflag (as has been done with kde-base/kdelibs, x11-terms/hanterm and x11-terms/mrxvt)? I noticed, that I had to chmod 0777 /var/run/screen to start the screen (not being run with group utmp anymore). I'm not sure if that is safe (Fedora uses a screen group and has /usr/bin/screen setgid for this), but the socket directories are owned by the relevant users and only accessible for them.
Created attachment 107953 [details, diff] screen-4.0.3.ebuild.patch Proposed changes including a new group "screen"
i dont really see much advantage with using a screen group over using the utmp group and no, doing chmod 777 on /var/run/screen is not safe also, utempter's use in screen is not like the other packages you cite, so i dont really think those are applicable examples
Well, group screen has no write access to /var/{run/utmp,log/wtmp} and I thought these two would deserve some protection against possible bugs/holes in screen. As for the differences in usage of utempter in screen and the other packages, could you please be a little bit more elaborate on that?
