Bugzilla Bug 83813

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 an attachment (id=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.