I installed dev-util/nsis-2.25 whick requires "Before you could emerge nsis, you need to install mingw32. Run the following command: emerge crossdev && crossdev mingw32" the install went fine, but now when I run emerge -p --depclean the list it gives me is: cross-mingw32/gcc selected: 4.1.2 protected: none omitted: none cross-mingw32/mingw-runtime selected: 3.12 protected: none omitted: none cross-mingw32/binutils selected: 2.17.50.0.12 protected: none omitted: none cross-mingw32/w32api selected: 3.9 protected: none omitted: none
Can crossdev maybe inject stuff into package.provided? That may allow depclean to leave it alone, CCing dev-portage for their thoughts.
(In reply to comment #1) > Can crossdev maybe inject stuff into package.provided? That may allow depclean > to leave it alone, CCing dev-portage for their thoughts. Sounds like a bad hack at best. Figuring out why depclean wants to remove those packages is likely the better option.
(In reply to comment #0) > the install went fine, but now when I run emerge -p --depclean the list it > gives me is: You can add them to your world file, for example: emerge --noreplace cross-mingw32/gcc cross-mingw32/mingw-runtime \ cross-mingw32/binutils cross-mingw32/w32api
Afaik, crossdev used to add the cross-toolchains to the world file, but that was removed for a reason (possibly because portage tried to upgrade them, and it never quite worked).
You can always use package.mask to mask anything greater than the current version so that it won't be upgraded automatically.
(In reply to comment #5) > You can always use package.mask to mask anything greater than the current > version so that it won't be upgraded automatically. > obviously the idea isn't to have a silly hack by manually adding them to the world file, or masking upgrades, but to either have the packages referenced properly in nsis, or to have crossdev properly handle the packages installs so package cleanup doesn't remove packages that are needed. In this case, I think it would be fine to just have nsis dependencies on the cross-mingw32/* packages that it needs. That really only solves the initial problem. Another solution may be to have crossdev maintain it's own package install list separate from the main emerge tree, and if crossdev is uninstalled, crossdev removes any packages it installed. Not sure how feasible this is with the current portage infrastructure, but it would solve the issue at hand of having a "second" package installer similar to emerge (even though it mostlickly just calls emerge for it's packages). This would prevent emerge from upgrading and removing the crossdev packages by emerge.
ive had many requests for crossdev to stop adding packages to world (and i agreed cause it annoyed me) if there's no real solution, then we'll just have to bit our lip and take it
(In reply to comment #7) > ive had many requests for crossdev to stop adding packages to world (and i > agreed cause it annoyed me) > > if there's no real solution, then we'll just have to bit our lip and take it > This request isn't about "sucking it up" or adding the packages to world, but thinking of a real solution to this problem. I think this should stay open until there is a proper solution. In the long run, we should be expecting emerge to be "autonomous" in that we shouldn't have to be careful of running depclean, but to just running it after removing a package that was installed to world and having it's dependencies removed without killing other applications and libraries. Finding the solution to this problem will help meet that future goal I think.
feel free to re-open once someone comes up with a real solution ... i have no problem adding one, i just dont think one exists here ;)
Eventually, we should be able to do cross toolchains as USE-dynamic SLOTs (bug 174407) instead of using the CATEGORY/symlink hack.
i'm not sure that'd address the issue here ... the packages would still not be added to world, and regardless of their $CATEGORY/$PN, nothing would depend on them directly ...
(In reply to comment #11) > the packages would still not be added to world, The user can add them to world if they want to, right? If we switch to using dynamic slots (bug 174407), then we'll need support for slot deps in the world file, but that's doable. > and regardless of their > $CATEGORY/$PN, nothing would depend on them directly ... The nsis ebuild calls mingw32-gcc at compile time, so it should be specified in the dependencies. Why not? I understand that it may be a workaround for some issue, but we should fix that issue rather than leave the dependency unspecified. The way that nsis currently dies in the setup phase seems analogous to built_with_use which will be obsolete when we get USE deps (bug 174406).
that would require the ability to use things like $CTARGET in SLOT ... while it works at the moment in portage, it isnt specified anywhere as being valid ...
Maybe it's a different kind of dynamic slot than what you had in mind for bug 174407. The requirement for any type of dynamic slot is that the package manager have some way to enumerate the possible values of the slot. For example, it could be done by adding CTARGET to USE_EXPAND and putting all the possible ctarget_* flags into IUSE for the package. Maybe that's not exactly how we should implement it. We can devise a more flexible way to enumerate them.
ive had that conversation already ... build machine names is not viable as a hardcoded list as it may literally contain an infinite number of values
I suppose it's still doable without enumerating all possible values. For example, we could have a new ebuild metadata variable called IUSE_EXPAND. The ebuild could set IUSE_EXPAND="CTARGET" in order to indicate that it responds to ctarget_* flags no matter when value CTARGET takes. If necessary, we could add an ebuild phase which allows for validation of the IUSE_EXPAND flags so that the package manager can bail out as early as possible if an invalid ctarget_* flag is chosen by the user.
After some discussion on irc with ferringb I'm convinced that each cross toolchains should be installed into a different "domain", which removes the need for dynamic slotting. Packages installed into different domains will, in effect, have separate /var/db/pkg databases so that their slots do not overlap with other domains.
crossdev reflects current portage capabilities ... portage cannot properly handle multiple gcc versions installed at once which differ only in SLOT (and CTARGET), so until that gets fixed, installing into a CTARGET based CATEGORY is the only usable solution
*** Bug 209366 has been marked as a duplicate of this bug. ***
(In reply to comment #9) > feel free to re-open once someone comes up with a real solution ... i have no > problem adding one, i just dont think one exists here ;) > An idea to solve the emerge --depvlean problem: To solve this problem, I created a "virtual" ebuild stating dependencies for the specific packages emerge by crossdev, which I then added to my world. -= EXAMPLE =- ~ $ crossdev -t powerpc-linux-gnu ~ $ cat >> $PORTDIR_OVERLAY/cross-powerpc-linux-gnu/toolchain/toolchain-0.ebuild << EOF # $Header: $ DESCRIPTION="Virtual for enviroments created by crossdev" LICENSE="none" SLOT="cross-powerpc-linux-gnu" KEYWORDS="x86" DEPEND=" =cross-powerpc-linux-gnu/binutils-2.19 =cross-powerpc-linux-gnu/gcc-4.3.3 =cross-powerpc-linux-gnu/glibc-2.9_p20081201-r1 =cross-powerpc-linux-gnu/linux-headers-2.6.28-r1 " RDEPEND="${DEPEND}" EOF ~ $ ebuild $PORTDIR_OVERLAY/cross-powerpc-linux-gnu/toolchain/toolchain-0.ebuild digest ~ $ emerge cross-powerpc-linux-gnu/toolchain -=THE END=- If this was done from within the crossdev-script, wouldn't that solve the problem described and still not have the created toolchains updated by portage?
(In reply to comment #20) > DEPEND=" > =cross-powerpc-linux-gnu/binutils-2.19 > =cross-powerpc-linux-gnu/gcc-4.3.3 > =cross-powerpc-linux-gnu/glibc-2.9_p20081201-r1 > =cross-powerpc-linux-gnu/linux-headers-2.6.28-r1 > " > RDEPEND="${DEPEND}" There's no need to put them in DEPEND. They should all go in RDEPEND like we do with new-style virtuals. > If this was done from within the crossdev-script, wouldn't that solve > the problem described and still not have the created toolchains updated by > portage? If you have cross-powerpc-linux-gnu/toolchain in your world file then `emerge --update --deep world` will update the dependencies of that ebuild.
(In reply to comment #21) > (In reply to comment #20) > > DEPEND=" > > =cross-powerpc-linux-gnu/binutils-2.19 > > =cross-powerpc-linux-gnu/gcc-4.3.3 > > =cross-powerpc-linux-gnu/glibc-2.9_p20081201-r1 > > =cross-powerpc-linux-gnu/linux-headers-2.6.28-r1 > > " > > RDEPEND="${DEPEND}" > > There's no need to put them in DEPEND. They should all go in RDEPEND like we do > with new-style virtuals. > > > If this was done from within the crossdev-script, wouldn't that solve > > the problem described and still not have the created toolchains updated by > > portage? > > If you have cross-powerpc-linux-gnu/toolchain in your world file then `emerge > --update --deep world` will update the dependencies of that ebuild. > Well then should we use <= instead of = ? Oh, and why is this WONTFIX? It's a real problem if you have x86 and x86_64 distcced or doing cross-mingw32 dev. I have 3-4 toolchains on my computer and well... the only ``real'' solution by now is to not use depclean. Talking of a real solution - what about a file /etc/portage/depclean-ignore, which portage reads and ignores those packages, and well, crossdev maintains?
Agreed, this wants fixing. It also affects anyone doing embedded development who has something like cross-avr/* installed. And WRT comment 21, why would emerge -uD world want to pull in higher versions of depended packages if they're depended on by an exact version? Surely installing version 1.2.3 of a package where a dependency says that exactly 1.2.2 is needed is just wrong and broken?
