From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 0E6851381F3 for ; Fri, 9 Nov 2012 21:02:28 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 9379421C00D for ; Fri, 9 Nov 2012 21:02:27 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 51663E0595 for ; Fri, 9 Nov 2012 18:21:57 +0000 (UTC) Received: from localhost (unknown [200.89.69.133]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: aballier) by smtp.gentoo.org (Postfix) with ESMTPSA id 98BE433D8F0 for ; Fri, 9 Nov 2012 18:21:55 +0000 (UTC) Date: Fri, 9 Nov 2012 15:21:45 -0300 From: Alexis Ballier To: gentoo-project@lists.gentoo.org Subject: Re: [gentoo-project] Council meeting: Tuesday 11 November 2012, 19:00 UTC Message-ID: <20121109152145.0249fe04@gentoo.org> In-Reply-To: <20121109153247.GA21483@linux1> References: <20121106212816.GE82762@gentoo.org> <20121108174548.GB3842@linux1> <20121108181557.GP83592@gentoo.org> <20121108185348.GB3931@linux1> <20121108204629.5ae6765d@gentoo.org> <20121109051346.GA20124@linux1> <20121109083355.248ffbe3@gentoo.org> <20121109153247.GA21483@linux1> Organization: Gentoo X-Mailer: Claws Mail 3.8.1 (GTK+ 2.24.13; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Project discussion list X-BeenThere: gentoo-project@lists.gentoo.org Reply-To: gentoo-project@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 3adb0b75-530c-43b5-8131-200eb05e7a5f X-Archives-Hash: 3b266064573505b1bc086bdfbe046a97 On Fri, 9 Nov 2012 09:32:47 -0600 William Hubbs wrote: > On Fri, Nov 09, 2012 at 08:33:55AM -0300, Alexis Ballier wrote: > > On Thu, 8 Nov 2012 23:13:46 -0600 > > William Hubbs wrote: > > > > > On Thu, Nov 08, 2012 at 08:46:29PM -0300, Alexis Ballier wrote: > > > > On Thu, 8 Nov 2012 12:53:48 -0600 > > > > William Hubbs wrote: > > > > > > > > > On Thu, Nov 08, 2012 at 07:15:57PM +0100, Fabian Groffen > > > > > wrote: > > > > > > On 08-11-2012 11:45:48 -0600, William Hubbs wrote: > > > > > > > > - approve/disapprove removal of gen_usr_ldscript > > > > > > > > > > > > > > A better way to put this is disabling gen_usr_ldscript on > > > > > > > Linux. Some of the alternate platforms still use it, so I > > > > > > > do not advocate killing the function. > > > > > > > If we go forward with the plan, there is no reason the > > > > > > > council should reject disabling gen_usr_ldscript on Linux > > > > > > > that I am aware of. > > > > > > > > > > > > > > This also has to wait until the blockers are resolved on > > > > > > > the tracker. > > > > > > > > > > > > Do you suggest to drop the point from the agenda? I'd love > > > > > > that. > > > > > > > > > > I believe we can drop the gen_usr_ldscript question, yes, > > > > > because if everything else happens, we can just have the > > > > > toolchain guys make it a noop on Linux. > > > > > > > > Something simpler and smoother imho is to just have a profile > > > > variable that will make gen_usr_ldscript a noop, whatever CHOST > > > > or the kernel is. New profiles are added with this variable > > > > set, wide testing can be done without forcing anyone, and > > > > voila. It is also simpler for maintaining the various OSes, > > > > packages that used to install to / can just be changed to > > > > install to /usr when this variable is set. > > > > > > I'm not trying to make packages install in /usr with this change. > > > > You are, since if a package in / needs a shared lib in /usr, there > > is absolutely no point in installing the package in /. > > nooping gen_usr_ldscript should come with a kind of plan for > > the /usr move otherwise it is a bit ugly and somewhat loses its > > point. > > No. All of this discussion about turning off gen_usr_ldscript on linux > applies *after* separate /usr support (either by an initramfs or with > the busybox[sep-usr] option) is implemented. Which is the only viable solution, I agree. > Once one of these options > is implemented, /usr is always available when / is, so the "barrier" > between / and /usr no longer exists. That just means you don't need > to move shared libraries to / for binaries in / to link to them. It > is the same as if you didn't put /usr on its own partition. To me, > your argument here about disabling gen_usr_ldscript is like saying, > if you put / and /usr on the same partition you should do a /usr move. Then why would you put anything in /, besides static binaries, after all this ? This is exactly what happened to udev & friends: after tons of """harmless""" additions that required /usr to be mounted, it has been decided that separate /usr isn't going to work anymore. You're only missing the last step: move it to /usr and at least have some benefits instead of artificially maintaining a non-working /usr barrier for historical reasons. Again, what is the point of having a binary in /bin that links to a library in /usr ? > > > gen_usr_ldscript was introduced to force shaired libraries that > > > upstream installs into /usr/lib to move to /lib and leave the > > > static libraries in /usr/lib. > > > > It's rather the opposite actually: very few upstream specify their > > install location, most default to /usr/local prefix because that's > > autotools default. econf (ie us) sets the prefix to /usr. > > gen_usr_ldscript is there because we don't need the static lib in / > > (so that setting libdir to /lib is not an option) while the shared > > lib is needed by binaries in /. We could just move the shared lib > > to / but then the linker may link to the static lib if /usr/lib > > comes before /lib in its search order, so we need a .so in the same > > dir as the .a. For example FreeBSD solved that differently: they > > symlink /lib/libfoo.so to /usr/lib/libfoo.so. Years ago we deemed > > symlinks crossing the /usr barrier were bad, and here comes > > gen_usr_ldscript. Note that I don't really see the difference > > between a symlink crossing the /usr barrier and a ldscript > > referencing a file outside of /usr but there must be some argument > > behind. > > I spoke to flameeyes about symlinks crossing the /usr barrier, wrt > another package, and he doesn't have a problem with this. I also have > never seen any policy etc deaming them bad, but that's another > discussion. Well, last time I tried this, portage threw out big fat warnings for such symlinks iirc. I'd call that policy :) > All I'm saying is that implementing separate /usr support on linux > eliminates the /->/usr barrier since / and /usr are always available > at the same time, thus eliminating the need for gen_usr_ldscript. Agreed, and also eliminating the need for separating /bin and /usr/bin > > Let's move everything to /usr/local :) there is not really a 'where > > upstream installs them' argument in this discussion, autotools is > > specifically designed so that distributions can tweak the install > > location. The fact that both the static and shared libs go to > > libdir is only a shortcoming of autotools, some other build systems > > make the distinction. > > I'm not familiar with many other build systems, so I can't really > comment specifically to this. But, I wonder why you would need to > separate where static and shared libs are installed. Because sometimes you need to call gen_usr_ldscript :) > > > Since we can tell we are on linux by looking at the chost/ctarget > > > variables, and there is not an intention to change anything for > > > *bsd or any other O/S, I am not sure I follow the need for a > > > profile variable. > > > > Testing it. Testing the /usr move broadly. > > You want gen_usr_ldscript on non-bootable systems (eg prefix, > > mingw) to be (mostly) a noop too which you can't distinguish from > > only CHOST. > > That has been done already by toolchain a while back. Take a look at > the code in toolchain-funcs.eclass. There are very few platforms > where this function does anything at all these days. It would just be > a matter of removing linux from the platforms it supports. Yeah, I remember that, and also when it completely broke freebsd-lib. Maybe that's the reason why I'm reluctant to hardcoding this :) [...] > > > If they want to discuss the gen_usr_ldscript issue I'm not > > > opposed to that, but that isn't really what I am asking for in > > > this meeting. > > > > IMHO this needs a discussion on -dev before going through the > > council. > > I would send the patch to do this to -dev anyway, so at that time I > guess we could have folks apply it and rebuild their systems and see > what breaks. > > Since applying the patch itself will not force any rebuilds, it > should just end up being a natural migration; as things are rebuilt > the libraries will move from /lib to /usr/lib with no harm being done. If you stop there then all what you get is an artificial /usr and / separation. According to Fedora, you gain much more with the /usr move than the few bytes you save without ldscript. Please give me a reason not to do an /usr move once you have covered all the needs to make it possible.