for example regexp -> regexp-bin in regards to if you had regexp merged, and it moved it to regexp-bin java-config -p regexp-bin (like used in ant-tasks) won't work options? 1) make java-config ignore -bin 2) remove -bin from path when installing 3) remove the move, and force updating 4) ?
4) just -p regexp,regexp-bin (probbaly best solultion?)
What would happen when we later on install regexp, then? Both classpaths are concatenated, with preference given to the source one? Let's take a step back for a moment and consider regexp. 1) Initial situation: dev-java/regexp is a binary-only package, but it's open-sourced. 2) We move it to dev-java/regexp-bin, since building from source will take a lot of work. 3) We later rewrite the ebuild to compile form source, and want to retire regexp-bin. No matter where in this process a user comes into the game, regexp must work. Also, he should not be required to upgrade manually at any stage. It should Just Work. If we follow zx's advice and just rewrite the "hidden" -bin packages, we can stop here. If we want to be consistent, we have to start thinking:) Let's break it down: 2) After the move, a user may or may not upgrade regexp afterwards. If he doesn't, the jar files stay in /usr/share/regexp/. If he does, they are now installed in /usr/share/regexp-bin. 3) When we write a new from-source ebuild, we have the same problem in reverse. AFAICT there are five cases from the above situation: 1) User never upgrades 2) User upgrades after move to -bin 3) User installs after move to -bin 4) User upgrades after move back to src 5) User keeps -bin In either case, having an ebuild depending on regexp do java-config -p regexp, regexp-bin will work because: 1) Either regexp or regexp-bin will be installed 2) Both cannot be installed at the same time. Since we do moves, there can only exist _ONE_ installable regexp candidate for the user at any one time: a) If the user has the "old" regexp and tries to install regexp-bin, portage will move regexp to regexp-bin before installing the -bin. b) If the user has regexp-bin, trying to install regexp (new), same story as (a). So, yes, I think your suggestion will work. However, it does print errors about the one alternative that is missing. We can probably just ignore that, CLASSPATH=$(java-config -p regexp,regexp-bin) will work regardless.
we could aways redirect stderr we talked on irc, to have -bin install to /opt/share and src to /usr/share, and have java-config search /usr/share first then /opt/share and use the name without -bin everywhere i think we should (i will if you think its a good idea) 1) update java-config to support this 2) adjust the java-pkg eclass to support this 3) bump all -bin packages, make them depend on java-config with ^ 3) adjust all ebuilds to use java-config -p package (without -bin) and the mess is gone? or did i miss something if we then move a pkg from -bin to src it shouldn't give any problems?
same Problme here but not not only with regexp. There are other packages that were renamed,too, which i had to mess around. dev-java/regexp-bin => dev-java/regexp gnome-base/ORBit => gnome-base/orbit gnome-base/ORBit2 => gnome-base/orbit-2 dev-java/avalon-logkit => dev-java/avalon-logkit-bin dev-python/PyOpenGL => dev-python/pyopengl Now the bad thing with is, you can
same Problme here but not not only with regexp. There are other packages that were renamed,too, which i had to mess around. dev-java/regexp-bin => dev-java/regexp gnome-base/ORBit => gnome-base/orbit gnome-base/ORBit2 => gnome-base/orbit-2 dev-java/avalon-logkit => dev-java/avalon-logkit-bin dev-python/PyOpenGL => dev-python/pyopengl Now the bad thing with is, you can´t even ugprage|remerge|unmerge these packages, because e.g.: These are the packages that I would merge, in order: Calculating dependencies - emerge: there are no masked or unmasked ebuilds to satisfy "dev-java/avalon-logkit". !!! Error calculating dependencies. Please correct. The only way that to get around this was to force emerge by doing: # emerge -Ca var/db/pkg/dev-java/avalon-logkit-bin-1.2.2/avalon-logkit-1.2.2.ebuild and then : emerge -a --noconfmem --oneshot avalon-logkit 1. is this the right bug report for that, or should I open an other one ? 2. The Problem here is, that the Ebuild from the Portage Tree had an other Name and Portage could it find anymore. Maybe it woult be better then to make s.th. like a version bump instead ? e.g. instead of just renaming the Ebuild ( what will lead to problems with allready installed Packages ) just "upgrade to an other Name": dev-java/regexp-bin-1.3 => dev-java/regexp-1.3-r1 !!! but without deleting to old one from portage !!!
you should be unable to unmerge dev-java/avalon-logkit since that no longer exist when you unmerge dev-java/avalon-logkit-bin, it should remove the previous dev-java/avalon-logkit install, that is the whole point too the 'move' i do not see any problems in your comment, and this isn't the right bug for it
You wrote: you should be unable to unmerge dev-java/avalon-logkit since that no longer exist ...and I wrote: These are the packages that I would merge, in order: Calculating dependencies - emerge: there are no masked or unmasked ebuilds to satisfy "dev-java/avalon-logkit". !!! Error calculating dependencies. Please correct. The only way that to get around this was to force emerge by doing: # emerge -Ca var/db/pkg/dev-java/avalon-logkit-bin-1.2.2/avalon-logkit-1.2.2.ebuild !!!!!! Since Portage couldn
You wrote: you should be unable to unmerge dev-java/avalon-logkit since that no longer exist ...and I wrote: These are the packages that I would merge, in order: Calculating dependencies - emerge: there are no masked or unmasked ebuilds to satisfy "dev-java/avalon-logkit". !!! Error calculating dependencies. Please correct. The only way that to get around this was to force emerge by doing: # emerge -Ca var/db/pkg/dev-java/avalon-logkit-bin-1.2.2/avalon-logkit-1.2.2.ebuild !!!!!! Since Portage couldn´t find dev-java/avalon-logkit anymore, it couldn´t unmerge it !!!!!!!!!!!!!! Yes I was able to "unmerge it" but _only_ with: emerge -Ca var/db/pkg/dev-java/avalon-logkit-bin-1.2.2/-1.2.2.ebuild and _not_ with: emerge -Ca avalon-logkit >> this produces the Errors Message above !!
sorry for my last comment. I was angry. because I know the difference between when portage behaves normal and when it does not. In particular when this is followed by an error message. I
sorry for my last comment. I was angry. because I know the difference between when portage behaves normal and when it does not. In particular when this is followed by an error message. I´m not a "hacker" but I´m also not stupid at all. so anyway here the bugreport. #62998 - Ebuild renaming caused Error Messages http://bugs.gentoo.org/show_bug.cgi?id=62998 have look there, it is what I really did
you would have been able to unmerge it with emerge -C avalon-logkit-bin This IS CORRECT portage behaviar (afaik) and this bug is about java renamed packages cauzing issues with java-config -p
closing
