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.60) (envelope-from ) id 1RiStk-0004MV-DU for garchives@archives.gentoo.org; Wed, 04 Jan 2012 15:37:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 3667921C06C; Wed, 4 Jan 2012 15:36:55 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id C620321C01F for ; Wed, 4 Jan 2012 15:36:28 +0000 (UTC) Received: from pomiocik.lan (unknown [81.219.203.13]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: mgorny) by smtp.gentoo.org (Postfix) with ESMTPSA id 3E0B81B4011; Wed, 4 Jan 2012 15:36:27 +0000 (UTC) Date: Wed, 4 Jan 2012 16:37:34 +0100 From: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= To: gentoo-dev@lists.gentoo.org Cc: tommy@gentoo.org Subject: Re: [gentoo-dev] rfc: locations of binaries and separate /usr Message-ID: <20120104163734.07439f2b@pomiocik.lan> In-Reply-To: <4F0440B3.4090500@gentoo.org> References: <4F000C32.6020602@gentoo.org> <1325449284.12935.21.camel@TesterTop4> <20120101202355.30098545@googlemail.com> <1325454648.12935.24.camel@TesterTop4> <4F016DBE.2000209@gentoo.org> <1325616625.7238.23.camel@TesterBox.tester.ca> <20120103190255.GA13817@linux1> <20120103191206.GP780@gentoo.org> <20120103200120.GB13936@linux1> <20120103212215.GU780@gentoo.org> <20120103230918.GA7247@linux1> <4F03A1AA.6070205@gentoo.org> <20120104091743.0e1cd91a@pomiocik.lan> <4F0440B3.4090500@gentoo.org> Organization: Gentoo X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.8; x86_64-pc-linux-gnu) 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: multipart/signed; micalg=PGP-SHA256; boundary="Sig_/vdo003SmK8RpxWjowJF3/Uy"; protocol="application/pgp-signature" X-Archives-Salt: 6e50dcff-4f38-43c7-97c4-e2980640e51c X-Archives-Hash: 25fa73ac20d5b9f4ad6c5d2a7d78f0c9 --Sig_/vdo003SmK8RpxWjowJF3/Uy Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, 04 Jan 2012 13:06:11 +0100 Thomas Sachau wrote: > Micha=C5=82 G=C3=B3rny schrieb: > > On Wed, 04 Jan 2012 01:47:38 +0100 > > Thomas Sachau wrote: > >=20 > >> 2. switching from udev to mdev (avoids required /usr of udev) > >> 3. some wrapper script to mount /usr before udev starts > >=20 > > These two should be really discouraged as a cheap, temporary > > solution. We should not support hate-admining. I personally think > > that busybox is ready to go into /usr even earlier than udev. >=20 > Please give us a bit more than just your opinion. >=20 > Why do you see mdev as a temporary solution? Because we will then return to this discussion at some later point and people will start throwing excrements at us again. So let's be done with this at once. > And this part was not about the movement to /usr at all, so why do you > suggest another movement here? And while you answer that, please also > tell us, why you want to migrate packages to a different install > location without a need. Because we need to finally be able to fix mistakes made in the past by other people. > >> For the idea of complete migration to /usr, i see no reason to go > >> this route in advance. Just keep with our default install > >> locations and follow upstream, if and where needed. > >=20 > > What about upstreams who do not care? In other words, all those > > packages which we hack to install into rootfs? >=20 > They install and work fine, so just keep it this way. I did not see > any argument to move packages around, that work well and have no > issue with their current install location. What if, say, upstream introduces pkg-config file where our hacks will cause it to be installed into /lib/pkgconfig? Should we then expand the hack to cover that, and something else, and then another thing... --=20 Best regards, Micha=C5=82 G=C3=B3rny --Sig_/vdo003SmK8RpxWjowJF3/Uy Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) iJwEAQEIAAYFAk8EckIACgkQfXuS5UK5QB0CUQP5AdG+Mf3/+6X5uAIYXU04b/lW qYwVhry6topeSYDU1P4ZTJQ93V8mbDYsZACpG43eoNmb1C/qCAWNY+PIJMW7fvHg +93soVaZ8LHvC0IoPHpi9pOViNq3BjdwXUzzUA2IBqEewUQTosPf38JDJpyn2JPx 97IogRN9Tl75N9GLGsg= =nsVe -----END PGP SIGNATURE----- --Sig_/vdo003SmK8RpxWjowJF3/Uy--