When I emerge qscintilla, version 1.61 installs. Next time around, 1.5-r1 shows up as the planned downgrade. If I accept this and emerge 1.5-r1, then 1.61 will be listed as the planned upgrade at the next emerge. [ebuild UD] dev-python/qscintilla-1.5-r1 [1.61] -doc 0 kB Reproducible: Always Steps to Reproduce:
Mask >=1.54 locally. I changed the versioning scheme and can't do anything about it, until 1.5 goes stable.
Same for me. Do I need to mask the newer version or it's ok to mask like: <=dev-python/qscintilla-1.61
OK i need to mask 1.61 cause eric3 depends on 1.5x
I've seen the same problem. One app wants an upgrade, another wants a downgrade. According to the eric3 web page it just needs QScintilla 1.0 or newer so 1.6x shouldn't be a problem. Also 1.62 is the current version but is not in portage. For some reason PyQT, like eric, also has a depend of "<dev-python/qscintilla-1.6" but Riverbank, the developer of both PyQT and QScintilla, offers the 3.14.1 and 1.62 versions respectively for download. One would think they work well together. Using overlay ebuilds I've installed qscitille 1.62 and succesfully emerged PyQT and eric (after removing the <dev-python/qscintilla-1.6 depend). If there is something that >qscintilla-1.6 really breaks I would like to know what it is.
Re: Comment #4: Chris: It appears to me that the problem is that the version numbering scheme of Qscintilla has been changed by Riverbank. The current version on their website is 1.5.1, "(based on scintilla 1.62)." It used to be that the Qscintilla versions tracked the scintilla versions. Thus, Qscintilla 1.61 was based on scintilla 1.61. However, with the new version numbering scheme, Qscintilla 1.5.1 (based on scintilla 1.62) is really newer than Qscintilla 1.61 (based on scintilla 1.61). As far as what is the difference between the versions, I'm not able to answer. However, I hope this clears up the versioning issue for you. If you want to be running the latest Qscintilla, it is 1.5.1. Howard
Re: Comment #5: Howard, good catch, thanks for the eye-opener. It actually appears from looking at the qscintilla ebuilds that this may not have been a change from Riverbank as it goes back to ebuild versions 1.4-r1 and 1.54 currently in the portage tree and probably even further. In fact the 1.4-r1 and 1.61 ebuilds rely on the same source package (just as 1.5 .1 and my home-rolled 1.62 do). The main difference I see between the ebuilds is that the "dual-digit numbered ones" (1.5x, 1.6x - those numbered for the scintilla versions) place files in the $QTDIR (compare the src_install sections in the ebuilds). This causes a problem for the PyQt ebuilds which don't build a critical package (qtext) needed for eric3 because the configure -n and -o options don't look in the $QTDIR path (I had to roll a new PyQt ebuild when I did the qscintilla-1.62 install). Yes 1.5.1 is the latest (or 1.62 if one was silly enough (like me) to create the ebuild without realizing the source file would be the same) and appears it's just the developers decision where he wants to place the headers, etc.
i agree with comment 5 and 6, so please delete the 1.6.x series from portage.
same here
Re comment 5 Looking at the ebuilds in portage (qscintilla-1.4-r1 qscintilla-1.5-r1 qscintilla-1.5.1 qscintilla-1.54 qscintilla-1.60 qscintilla-1.61) it does seem as though the version numbering change was local. The /usr/portage/dev-python/qscintilla/ChangeLog indicates the versioning was fixed with 1.4 and 1.5 *qscintilla-1.5 (20 Feb 2005) 20 Feb 2005; Carsten Lohrke <carlo@gentoo.org> +files/qscintilla-1.4-sandbox.patch, +files/qscintilla-1.5-sandbox.patch, +qscintilla-1.4.ebuild, +qscintilla-1.5.ebuild: correcting versioning and bump Looking at the Riverbank website changelog it seems they have (always?) used a number compound numbering scheme like qscintilla-1.62-gpl-1.5.1.tar.gz where the Scintilla version and the qscintilla version are both given - and not explicitly matched. So I guess masking is the way to go until {1.60,1.61} are removed from the portage tree. No way to tell portage that the order of ebuilds/versions is other than numerical is there? (I'm here because of an issue with hplip, which uses PyQt)
This problem has been exacerbated by the addition of qscintilla-1.65 to the tree.
Please see my comment 4 to bug #101154. Carsten, I recommend the following correction: Please mask ALL versions of qscintilla > 1.6, because the numbering scheme used by Gentoo is _different_ than the one used upstream by Riverbank. The latest version of QScintilla is 1.6. I am attaching a 1.6 ebuild. This is _identical_ to the 1.65 ebuild currently in portage. However, it uses the upstream numbering which is what I believe we should use from now on.
Created attachment 70800 [details] Ebuild renumbered to 1.6. This is identical to 1.65 ebuild. Please see comment #11.
this situation with qscintilla is really frustrating. I'm trying to build eric3, but it keeps giving me errors about building PyQt with qscintilla support. Am I supposed to use the newest ebuild to be added to the tree, 1.65, or am I supposed to use 1.5.1? eric keeps complaining: "Sorry, please install QScintilla and/or reinstall PyQt with QScintilla support. Error: No module named qtex", and I'm wasting time fighting with portage instead of doing my work.
when pyqt-3.15 is built against qscintilla-1.5.1, the qtext module is not built. as a result, eric3 does not build either. eric3 has <qscintilla-1.6 listed as its dependency, which I changed to "qscintilla". I was able to emerge eric3 after emerging qscintilla-1.65. This version numbering issue has really got to be resolved.
*** Bug 101154 has been marked as a duplicate of this bug. ***
*** Bug 93481 has been marked as a duplicate of this bug. ***
*** Bug 115638 has been marked as a duplicate of this bug. ***
Please, fix this versioning mess. I don't understand why this broken versioning scheme has been introduced in the first place, because it's pretty obvious that it won't work correctly. Upstream offers qscintilla-1.65-gpl-1.6.tar.gz so why we have things like 1.5.1 and 1.6 in portage? | a a a h i m m p p p s s s x | l m r p a 6 i p p p 3 h p 8 | p d m p 6 8 p c c c 9 a 6 | h 6 a 4 k s 6 - 0 r | a 4 4 m c | a | c | o | s ------+---------------------------- 1.5.1 | ~ ~ ~ + ~ ~ + 1.6 | ~ ~ ~ ~ ~ ~ ~ 1.54 | + + + + + + 1.60 | + + ~ + + + 1.61 | + + + + + + + 1.65 | ~ ~ ~ ~ + ~ ~ So, what needs to be keyworded? Whatever version it is, file a keywording bug for that and once it's done, purge the huge mess from the tree so that the dependencies can work correctly in other ebuilds (like dev-util/eric) ...
(In reply to comment #18) > Please, fix this versioning mess. I don't understand why this broken versioning > scheme has been introduced in the first place, because it's pretty obvious that > it won't work correctly. Upstream offers qscintilla-1.65-gpl-1.6.tar.gz so why > we have things like 1.5.1 and 1.6 in portage? Comment #5 answers this question
what if the numbering scheme was changed so that the current version, qscintilla-1.65-gpl-1.6, is called qscintilla-1.65.1.6 in portage? Wouldnt that solve these problems?
As far as I can tell comment #5 got it right: upstream's qscintilla-1.65-gpl-1.6 really means "qscintilla-1.6, based on scintilla-1.65". The 1.6 version is the important one. So to fix this mess: - mark 1.5.1 stable on all archs qscintilla is keyworded for. This is qscintilla-1.62-gpl-1.5.1, so newer than anything else with stable keywords, and it has been in the tree for months. Affected archs: amd64, alpha, ia64, ppc64, sparc. - mark 1.6 stable on ppc64. This is qscintilla-1.65-gpl-1.6. 1.65 installs the same tarball, and is currently marked stable on ppc64. - remove all qscintilla versions except for 1.5.1 and 1.6 from the tree, fixing depends as necessary. I'm cc-ing the affected archs, and will do the final step once everything is keyworded.
(In reply to comment #21) > - mark 1.5.1 stable on all archs qscintilla is keyworded for. Full stop. You can't just mark it stable.
This was solved for us on bug #117246 if i'm right so un-CCing us.
Following gustavoz's steps ... same case for alpha :)
same here.
amd64 too...
It is happening here too Portage 2.1_pre4-r1 (default-linux/amd64/2005.0, gcc-3.4.5, glibc-2.3.6-r2, 2.6.15-gentoo-r1 x86_64) ================================================================= System uname: 2.6.15-gentoo-r1 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.0_pre15 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.4 [enabled] dev-lang/python: 2.4.2-r1 sys-apps/sandbox: 1.2.17 sys-devel/autoconf: 2.13, 2.59-r7 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.16.1-r1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /usr/share/cursors/xorg-x11/default /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-march=athlon64 -pipe -O2 -fomit-frame-pointer -frename-registers" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LANG="sl_SI" LINGUAS="en sl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/root/portageoverlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X a52 aac acl acpi alsa amd64 apache2 apm arts audiofile avi berkdb bitmap-fonts bzip2 cairo cdr crypt cups curl dbus dts dvd dvdr eds emboss encode esd exif expat fam fbcon ffmpeg flac foomaticdb fortran freetype ftp gif gmp gnome gphoto2 gpm gstreamer gtk gtk2 hal idn imagemagick imlib ipv6 jabber jpeg kde lcms lm_sensors lzw lzw-tiff mad matroska mng mozilla mp3 mpeg mysql ncurses nls nptl nptlonly nvidia ogg opengl oss pam pdf pdflib perl php png posix ppds python qt quicktime readline samba scanner sdl slp speex spell sqlite ssl stream subversion svg tcpd tetex theora tiff truetype truetype-fonts type1-fonts unicode usb userlocales vhosts videos vorbis xcomposite xine xml xml2 xmms xosd xpm xprint xscreensaver xv xvid zlib elibc_glibc kernel_linux linguas_en linguas_sl userland_GNU video_cards_nvidia" Unset: ASFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, LC_ALL, LDFLAGS
Could all the versions greater than 1.6 be renamed. The ebuilds greater than 1.6 are versioned from the scintilla version _not_ the qscintilla version. In fact, the 1.6 and 1.65 versions are the exact same package. (I am currently caught in the dreaded upgrade<->downgrade cycle for these two.)
(In reply to comment #28) > Could all the versions greater than 1.6 be renamed. Uh... seriously, read the whole story and Bug 117246 before posting such requests.
cvs should be clean now.
