From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.77) (envelope-from ) id 1SpZOd-0000S8-Cw for garchives@archives.gentoo.org; Fri, 13 Jul 2012 06:30:35 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id F281BE06F3; Fri, 13 Jul 2012 06:30:16 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id D87CFE0329 for ; Fri, 13 Jul 2012 06:29:40 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 483EF1B40BD for ; Fri, 13 Jul 2012 06:29:40 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5.5 tests=[AWL=-0.562, BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3EQl3WVghIn for ; Fri, 13 Jul 2012 06:29:34 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 4EE2E1B4054 for ; Fri, 13 Jul 2012 06:29:33 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1SpZNZ-0007Gp-V4 for gentoo-dev@gentoo.org; Fri, 13 Jul 2012 08:29:30 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Jul 2012 08:29:29 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 13 Jul 2012 08:29:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: rfc: udev-rules.eclass Date: Fri, 13 Jul 2012 06:29:13 +0000 (UTC) Message-ID: References: <20120711191142.GA26844@linux1> <4FFDE8C6.40006@flameeyes.eu> <20120711234230.GA27226@linux1> <20120712091754.2480af4a@pomiocik.lan> <4FFE7DDE.6040107@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.139 (Sexual Chocolate; GIT 014d082 /usr/src/portage/src/egit-src/pan2) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: bb634be5-1385-4c2b-8a1d-307ebc1e0b9c X-Archives-Hash: 0799bf0f7ef344da621bc80048d77d8d Zac Medico posted on Thu, 12 Jul 2012 00:33:50 -0700 as excerpted: >>> Couldn't you, on udev upgrade, move everything in /lib/udev to >>> /usr/lib/udev, and then make the symlink? Seems fairly simple to me, >>> but maybe I'm overlooking something? >>=20 >> You are overlooking conflicts introduced through moving files without >> updating vardb. >>=20 >>=20 > Maybe that's package manager dependent. I think it should work fine wit= h > Portage though. Confirmed. This is the way amd64 has handled the lib -> lib64 symlink=20 (sometimes reversed) for years (which is why the whole FEATURES=3Dmultili= b- strict thing was needed to try and keep things straight). As long as the= =20 symlink is there, portage will follow the symlink and manage the files=20 just fine. FWIW, a similar trick was used when migrating X-related stuff from=20 /usr/X11R6/ to simply /usr/ . The files were moved up a level into /usr,= =20 and /usr/X11R6 became a symlink -> . , thus pointing back to /usr/ . =20 IIRC, existing package versions still continued to own their /usr/X11R6/ *, the DB wasn't changed. New versions simply moved directly into /usr/,= =20 and the problem gradually solved itself until it was down to a manageable= =20 size for a final push to get the old location out of the tree. (I just=20 checked and it appears nothing owns that symlink on my system, now...=20 unless I screwed up my equery|grep... ) Now if the symlink somehow gets lost before all packages have moved their= =20 paths... But that trick has been used enough in gentoo, especially in gentoo/ amd64, that every PM should cope with it just fine, or said PM would be=20 rather broken. --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman