From use.desc: dedicated - Adds support for dedicated game servers However, when emerging games-simulation/openttd with +dedicated you get this message: You have chosen the dedicated USE flag which builds a version of OpenTTD to be used as a game server which does not require SDL. You will not be able to play the game, but if you don't pass this flag you can still use it as a server in the same way, but SDL will be required. Thus, in this ebuild dedicated does not "Add support for dedicated game servers" but rather "Removes support for non-dedicated game servers". I have not looked into the ebuild closely, but from the messages I got during the emerge it seems that it's not possible to actually build the game without dedicated support. If that is so, the dedicated use flag is inappropriate. In any case, the current use of the dedicated use flag is inappropriate (or at *least* misleading). If the behavior enabled by the dedicated use flag is kept (and I see so reason not to), it should use a different, probably local, use flag. I would suggest this flag be dedicatedonly, but that's just a suggestion. As a workaround, don't emerge games-simulation/openttd with the +dedicated. If you still desire dedicated for the rest of the ebuilds that use the flag, simply add 'games-simulation/openttd -dedicated' to /usr/portage/package.use or create that file with those contents (nothing else is required in the file). Reproducible: Always Steps to Reproduce: 1. emerge games-simulation/openttd with +dedicated 2. Notice message stating the game is actually unplayable. :( Actual Results: I had emerged a non-playable version of OpenTTD. Expected Results: Provided both a locally playable version *and* a dedicated server. Portage 2.0.51.22-r1 (default-linux/x86/2005.0, gcc-3.4.3-20050110, glibc-2.3.5-r0, 2.6.11-gentoo-r6 i686) ================================================================= System uname: 2.6.11-gentoo-r6 i686 Pentium II (Deschutes) Gentoo Base System version 1.6.12 distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.8 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r1, 2.16 sys-devel/libtool: 1.5.18 virtual/os-headers: 2.6.8.1-r1, 2.6.11 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-march=pentium2 -O3 -fomit-frame-pointer -fforce-addr -fno-keep-static-consts -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=pentium2 -O3 -fomit-frame-pointer -fforce-addr -fno-keep-static-consts -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="ftp:///ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ http://gentoo.binarycompass.org http://ftp-mirror.internap.com/pub/gentoo/ http://mirror.datapipe.net/gentoo http://mirror.datapipe.net/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.namerica.gentoo.org/gentoo-portage" USE="x86 X aalib alsa apm arts audiofile avi berkdb bitmap-fonts cdparanoia cdr crypt cups curl dedicated directfb divx4linux dv dvd dvdr dvdread emboss encode esd fam flac foomaticdb fortran gd gdbm gif gnutls gpm gtk gtk2 imagemagick imlib innodb ipv6 java jce jpeg junit kde libg++ libwww mad mikmod mmap mmx motif mozilla mp3 mpeg mysql ncurses nls nptl odbc ogg oggvorbis opengl pam pcre pdflib perl png postgres python qt quicktime readline samba sdl sndfile spell ssl svga tcpd tetex theora tiff truetype truetype-fonts type1-fonts vorbis win32codecs xine xml2 xmms xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS
Created attachment 60166 [details, diff] openttd-0.4.0.1.ebuild.diff Not sure if this change would require a version bump, so I'm providing patches to all the ebuilds and use.local.desc. If it does require a version bump, you'll only need the 0.4.0.1 and use.local.desc patches.
Created attachment 60167 [details, diff] use.local.desc.diff
Created attachment 60168 [details, diff] openttd-0.4.0.ebuild.diff
Created attachment 60169 [details, diff] openttd-0.3.6-r1.ebuild.diff
Darn it, I was hoping the filename I used (<original name>.diff) would show through at some level. Rather than spamming bugzilla simply changing the descriptions (esp. since I don't know if the patches will be used) I'll post the file names here: 60166 - openttd-0.4.0.1.ebuild.diff 60167 - use.local.desc.diff 60168 - openttd-0.4.0.ebuild.diff 60169 - openttd-0.3.6-r1.ebuild.diff I'm sure an actual bug-wrangler can change the description, or at least drop me an email saying I should, if it really has to be done.
Hmm, you use dedicated, get dedicated game server and complain that it
Hmm, you use dedicated, get dedicated game server and complain that it´s not what you want? I don´t understand what´s to be patched here...
> Hmm, you use dedicated, get dedicated game server and complain that it
> Hmm, you use dedicated, get dedicated game server and complain that it´s not > what you want? I don´t understand what´s to be patched here... Dedicated /adds/ support for dedicated servers. (See use.desc or read my exerpt in the original description.) It *should not* /remove/ support for local play. In this case, that's exactly what it does. (See the ebuild, particularly the message I quoted in my original description.) In fact, you can run a dedicated server even if you don't build with +dedicated! It's simply use flag abuse / overuse. My patches change the flag to be something other than dedicated (so the flag doesn't get abused / overused). The new flag, dedicatedonly, is also more descriptive / accurate.
It is like this with a lot of ebuilds, why make a problem of it?
that's what dedicated means.
+1 to Mr_Bones_ for keeping current behavior
> It is like this with a lot of ebuilds, why make a problem of it? Because, at the very least, it IS a documenation problem. I think problems should be fixed. The dedicated use flag does not say it will remove local client functionality, therefore it shouldn't. > that's what dedicated means. Well, then change use.desc to reflect that. The current description says nothing about preventing local play. It reads like it adds to the package, not takes away. This is a bug. I guess I just saw the wrong part as broken. > +1 to Mr_Bones_ for keeping current behavior -2 to SpanKY for hitting bugzilla (and all of our inboxes) with a content-less post. Anyway, the bug is not invalid, the fix I've provided is.
ah muffin, i didnt realize you'd bitch over something so small i'll change the desc to read 'some packages are unable to sanely provide both the server and client at the same time'
> i'll change the desc to read > 'some packages are unable to sanely provide both the server and client at the > same time' I don't think that's the case here; is it? I just looked though the ebuild and it looks like I'd have to delve into the Makefile to actually tell. However, an excerpt from the ebuild messages sounds like it addresses the issue: "...if you don't pass this flag [dedicated] you can still use it as a server..." so this package can apparently give a dedicated server and a local client with no problems. I'm still not convinced the dedicated use flag is entirely appropriate here. This ebuild needs a flag that says, out loud: "By turning me on, you are removing functionality and gaining none." We have such flags portage already. One example is nptlonly. Others, like moznomail or moznoxft, exist as well. Dedicated, both as written and as ammended, doesn't fit this role. In both cases, it reads like you get something extra and, with this ebuild, you don't. I have proposed "dedicatedonly" (and provided patches to that ends), which is clear and correct. An alternative could be "ottdnoclient" or simply "noclient", but I have a reflexive dislike for negative flags.
