Duncan wrote: >Pascal BERTIN posted <[EMAIL PROTECTED]>, excerpted below, on >Fri, 01 Apr 2005 18:42:42 +0200: > > > >>but as (if I understand correctly (being less smart than other :-( )) we >>have multilib support without multilib USE flag >>emerge will not remerge (with --newuse) affected packages and you have >>to re-emerge them yourself, and it looks that dependencies don't work >>either (see previous mail) >>so maybe portage has to be fixed to handle this. >> >> > >If you didn't have multilib in your USE flags b4, that is (I believe, I >had it here so can't check) correct -- emerge --newuse won't catch the >packages. > >However, there are only a few packages so affected, so far. Mainly gcc, >glibc, and portage itself. That's because -- getting into the other >aspect of your comment -- you are correct, portage doesn't yet know how to >manage separate dependencies for 32-bit and 64-bit -- the functionality >isn't there yet. > >That's the next piece of the puzzle, and what they hope to have ready by >2005.1, by which time they hope portage-2.0.52 will be out, with the >included functionality. After portage can properly and concurrently track >separate dependencies for 32- and 64-bit, /then/ it'll be time to start >modifying all the library ebuilds, so they'll automatically merge both >bitness versions if the profile is set up for it. That'll be continuing >work thru at least 2006.0, starting with the libraries we currently merge >the binary compatibility versions of, and continuing thru all the >arch-marked libraries in the tree. > > > ok, so maybe, just in order to prevent that further "emerge --newuse -puDv world" proposes to reemerge gcc (because it was last emerged with multilib USE flag on), we could add to the Makefile & the migration guide a (sed) command that would remove multilib from /var/db/pkg/sys-devel/gcc-<current-version>/USE
Pascal -- [email protected] mailing list
