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 <gentoo-dev+bounces-53304-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>;
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 <gentoo-dev@gentoo.org>; Fri, 13 Jul 2012 06:29:33 +0000 (UTC)
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <lnx-gentoo-dev@m.gmane.org>)
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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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: <pan.2012.07.13.06.29.13@cox.net>
References: <20120711191142.GA26844@linux1> <4FFDE8C6.40006@flameeyes.eu>
<20120711234230.GA27226@linux1>
<CAB9SyzQUv_S3MPEc7=rCbckoYuUjQLLwhV+X+RP4eX2d5QB7TQ@mail.gmail.com>
<20120712091754.2480af4a@pomiocik.lan> <4FFE7DDE.6040107@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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