Wine 0.9 is a newer release than the 2005xxxx snapshots, however it is not emerged with emerge -u world or emerge wine, and if I manually emerge it (emerge =wine-0.9) this is seen as a downgrade, and the next time I emerge -u world it will attempt to revert to a 2005xxxx version. Reproducible: Always Steps to Reproduce: 1. Set ACCEPT_KEYWORDS to ~x86, or app-emulation/wine ~x86 in /etc/portage/package.keywords 2. emerge =wine-0.9 3. emerge -puv world Actual Results: These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild U ] app-emulation/wine-20050930 [0.9] +X +alsa +arts +cups -debug +esd +gif +glut +jack +jpeg +lcms +ldap -nas +ncurses +opengl -oss -scanner +truetype +xml2 0 kB Total size of downloads: 0 kB md401 ~ # Expected Results: Nothing should have been found to upgrade, as 0.9 is the newest version of wine. md401 ~ # emerge info Portage 2.0.51.22-r3 (default-linux/x86/2005.1, gcc-3.3.6, glibc-2.3.5-r2, 2.6.13-gentoo-r3-mikeyd i686) ================================================================= System uname: 2.6.13-gentoo-r3-mikeyd i686 AMD Sempron(tm) Processor 2600+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 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.6-r1 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /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/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.blueyonder.co.uk ftp://mirrors.blueyonder.co.uk/mirrors/gentoo http://www.mirrorservice.org/sites/www.ibiblio.org/gentoo/ ftp://ftp.mirrorservice.org/sites/www.ibiblio.org/gentoo/ " LINGUAS="en_GB" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowext X X509 Xaw3d a52 aac aalib acl ada adns aim alsa apm applet ares arts artswrappersuid async audiofile authdaemond avi bash-completion bitmap-fonts bonobo browserplugin bzip2 caps cddb cdparanoia cdr cdrom chroot cjk clearcase crypt cups curl dga directfb dlloader doc dts dv dvd dvdr dvdread ecc eds emacs emboss encode esd exif expat fam fame fbcon ffmpeg flac flash fontconfig foomaticdb fortran fpx gcj gd gd-external gdbm ggi gif glibc-omitfp glut gmp gnome gnome-print gnomedb gnutls gphoto2 gpm graphviz gstreamer gtk gtk2 gtkhtml guile hal haskell hbci howl hpn icq idea ieee1394 imagemagick imap imlib insecure-drivers insecure-savers ipv6 irc ithreads jabber jack java javascript jbig joystick jpeg jpeg2k kde kdeenablefinal kqemu lcms ldap leim libcaca libedit libg++ libwww live lj lzo mad mailwrapper matroska mcal mdb migemo mikmod mjpeg mmap mmx mmxext mng mono motif mozcalendar mozdevelop mozilla mozsvg mp3 mpeg mpi msn music musicbrainz mysql ncurses netboot network new-login nls nntp nodrm nowin nptl nptlonly nsplugin nvidia objc offensive ofx ogg oggvorbis on-the-fly-crypt openexr opengl pam pascal pccts pcre pdflib perl pg-hier php physfs png postgres povray python qt quicktime rdesktop readline real rss rtc ruby samba sasl sdk sdl sensord sftplogging skey slang slp sndfile socks5 source speex spell sql sqlite sse sse2 ssl subp subversion svga symlink tcltk tcpd tetex tga theora threads tidy tiff toolbar transcode truetype truetype-fonts type1-fonts ucs2 udev unicode vcd vcdimager vidix vim-with-x visualization vorbis win32codecs winbind wmf xanim xface xine xml xml2 xmms xprint xscreensaver xv xvid xvmc yahoo yaz yv12 zeroconf zlib linguas_en_GB userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS md401 ~ #
*** Bug 110517 has been marked as a duplicate of this bug. ***
usual workaround for this is to add the line: ">=app-emulation/wine-9999" (without quotes) to the /etc/portage/package.mask file. At least this solves the issue "client-side", but it's not a permanent solution nor will close this bug....
known issue i'm not going to do anything about it until i see how wine will be making releases in the future
You could at least remove the arch flags from or mask old ebuilds like for -1000. If wine continues to release by date, releases newer than 0.9 could still have arch flags or be unmasked. This leaves old releases available but saves time and thinking.
as i said, there's no point in worrying over the situation until the next release when we see if they are going to continue with the 0.9 style versioning or just make another cvs-dated snapshot
wouldn't slotting 0.9 get around this at least to some extent? BTW would Cantfix or Wontfix be more accurate than Fixed? Since it clearly is a bug and clearly is not fixed.
no idea wtf you're talking about seeing as how the bug is still open and thus not marked FIXED/CANTFIX/WONTFIX and no, SLOT-ing isnt just as simple as changing the value from '0' to something else ... SLOT-ing versions usually takes work when upstream doesnt normally intend for multiple versions to be installed at the sametime
maybe add =app-emulation/wine-20* to the current package.mask in the profile? This way users will be alerted a newer release is in portage. People who want to use a "cvs diff version" can unmask it locally.
no, not a valid solution lemme reiterate the point that i'm not going to do anything until at least the next release people who want the newer version can mask the 200* ones locally
i think a simple and valid solution is: wine-0.9 --> wine-20051025-0.9 or simply wine-20051025 (release date)
no, it isnt
why not? another solution is removing old ebuids, but next release you'll have the same problem.
As for the removal of old ebuilds, see bug #87865.
Why not use a version scheme like this for the older snapshots: wine-0.9_pre2005xxxx
(WineHQ Press Release Post) -quote- "<snip> While the core internals of Wine are now complete, there remains a lot of work fleshing out various DLL's. In the course of discussion, Alexandre mentioned some of the things that need to get fixed **before 1.0**: we still have a lot of work to do on usability issues (winecfg, desktop mode, cdrom support, systray, etc.), and we need better support for the various code obfuscation tools, it's probably the number one cause of apps not even starting today. Jonathan Wilson asked if that last item meant support for Safedisc, Securom and other copy protection methods. Alexandre replied, As far as possible, yes. I think the goal **for 1.0** should be that anybody has to be able to try Wine and see that it's for real. This means they must not be stopped either by not being able to configure it, or by apps failing to even start. <snip>" --- I believe they will call the next version 1.0 instead of the usual 2005xxxx ... But I think those who are interested in Wine already read this article :)
comment #14 seems a good solution too for me..
Even if the wine guys would fall back to dates, I think it would be better to use 0.9-YYYYMMDD untill they release 1.0, that way this problem won't appear again. Took me a quite long time before I got 0.9 emerged, as I thought that the usual lagness in gentoo was in question, not that the older versions was classed as newer than the newest version by portage.
it looks like 0.9.1 was released.
in portage
Comment 18 and 19: And so was 0.9.2. So now you got two releases "confirming" the new versioning scheme as you insisted on seeing before fixing the breakage, plus Wine's press release about going into beta, using 0.9.x versions for it and heading for 1.0 soon, which in itself is pretty clear statement that they intend to stick with new version numbers.
As noted, it looks like 0.9.x is now the de facto standard for Wine releases. Can portage be updated so that 0.9.2 is now the standard Wine install (on ~x86)? This has now become an issue on the forums.
(In reply to comment #17) > Even if the wine guys would fall back to dates, I think it would be better to > use 0.9-YYYYMMDD untill they release 1.0, that way this problem won't appear again. The above wouldn't be a valid ebuild version number. But having used only the date as version number is the problem in the first place. Just renaming the existing ebuilds to wine-0_preYYYYMMDD will work fine. Same procedure, if wine.org falls back using date codes later (e.g. wine-1.1_preYYYYMMDD).
*** Bug 116055 has been marked as a duplicate of this bug. ***
*** Bug 117199 has been marked as a duplicate of this bug. ***
Time has gone on since this bug was reported, wine has released versions 0.9.3 and 0.9.4. Something should be done about this bug, as currently it's unobvious for users (for me, at least) that these versions actually exist in portage.
That's right, it is your call fellows... Until i checked bugzilla and found this bug here i was in belief that the -2005???? version was somehow superior or more bug-free then the 0.9.x ones... Obviously i was mistaking.. but the err was not mine. (In reply to comment #25)
I encountered this bug while looking for a solution to wine-20050930 not compiling with the new gcc-3.4.5. As a solution, i emerged wine-0.9.4 successfully, and got rid of this bugs issue with the following: --- # echo "=app-emulation/wine-200*">>/etc/portage/package.mask # emerge -pv wine These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] app-emulation/wine-0.9.4 USE="X alsa arts esd gif glut jpeg lcms ncurses opengl oss truetype xml2 -cups -debug -jack -ldap -nas -scanner" 0 kB Total size of downloads: 0 kB --- HTH.
(In reply to comment #27) i prefer this way because of possible cvs snapshots in 2006 8-) grep wine /etc/portage/package.mask =app-emulation/wine-2005* =app-emulation/wine-2004*
(In reply to comment #28) > (In reply to comment #27) > > i prefer this way because of possible cvs snapshots in 2006 8-) > > grep wine /etc/portage/package.mask > =app-emulation/wine-2005* > =app-emulation/wine-2004* > Right... I don't think you have RTFM (well, in this case, the various documents regarding Wine development), but the date-version CVS snaps for wine are gone, and they aren't coming back, like New Orleans. This has been verified by Alexandre Julliard, who is the guy that runs the show (he is to Wine as Linus Torvalds is to the Linux Kernel, for those that don't know)
(In reply to comment #3) > known issue > > i'm not going to do anything about it until i see how wine will be > making releases in the future Any chance of a real resolution of this "FIXED" bug I think the pattern has been established in 6 releases now and ppl are still getting caught out by this portage BUG. new package name? slots ? you know the way it works best. Thx
fixed
Well at least that's a quick hack so that the security team dont get confused any more ;) although hardmasking half the tree may not be the most flexible solution in the long term. Some of the older wine version are useful (I guess that's why there are so many in the tree still.) Maybe splitting off the older wine into a different package (wine-alpha?) or slotting and adding an Ewarning about the bug would be tidier. Since wine-0.9....0.9.4 is no more secure to the wmf "feature" it does not actually ensure ppl upgrade but at least the lastest will now appear as the latest. That will make for less confusion, thanks.
I think Comment 14, though imperfect, is a better solution than currently.
the security team wasnt confused, i gave them wrong information stop blaming the wrong person
