From owner-freebsd-hackers@FreeBSD.ORG Thu Dec 13 09:08:36 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8CAEE16A417 for ; Thu, 13 Dec 2007 09:08:36 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id E769913C4D1 for ; Thu, 13 Dec 2007 09:08:35 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A553DD.dip.t-dialin.net [84.165.83.221]) by redbull.bpaserver.net (Postfix) with ESMTP id 027062E0C1; Thu, 13 Dec 2007 10:08:27 +0100 (CET) Received: from webmail.leidinger.net (webmail.Leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id E1F2C77855; Thu, 13 Dec 2007 10:08:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=Leidinger.net; s=outgoing-alex; t=1197536903; bh=4KP4VCFeytdLQAcizwX6F5xnqevXqKqNR DbfFb6Bbm4=; h=Message-ID:X-Priority:Date:From:To:Cc:Subject: References:In-Reply-To:MIME-Version:Content-Type: Content-Disposition:Content-Transfer-Encoding:User-Agent; b=At+8uA DSKItlp75JQ5Bp6Sme1Ev6omkiEIQGjjJIyPCQl8rJcdmG2AAjsBTdTQams3fBMGeJK IOy8SNlfiJPoKX0swR4s91tLENxFGH8jgAr2X6918ZEGYvxMY+SPrm+EQL9ELCnz1NC zuwKMjhwd6R0RKjA/tP0t9IEu7THjnzs2F5ILBRpEnMEKRENqoM3ZrKCjR20OlEP9JN 7eKdh1abRvElIfEBdMgOwsZZLoz1BAt9lymu9BcG2zShBkJozPJdjnQAvtJG8tfl7TD T3InH8Ej2/QHX5DeWmoJJy5nVF+W6EjB5m1oatyjQfv4XIU7wg0WBQAtVmv3Mn0gY90 w== Received: (from www@localhost) by webmail.leidinger.net (8.14.1/8.13.8/Submit) id lBD98Lu7077050; Thu, 13 Dec 2007 10:08:21 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Thu, 13 Dec 2007 10:08:21 +0100 Message-ID: <20071213100821.bet532peog8g488s@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Thu, 13 Dec 2007 10:08:21 +0100 From: Alexander Leidinger To: Chuck Robey References: <1196470143.4750af7f6accf@webmail.rawbw.com> <4752F825.8020505@chuckr.org> <20071203144159.irjelm2c0c8o8csw@webmail.leidinger.net> <47544B5A.9080903@chuckr.org> <20071205122123.phwu6uh7jksgcwk8@webmail.leidinger.net> <4760A7FE.9070409@chuckr.org> In-Reply-To: <4760A7FE.9070409@chuckr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.4) / FreeBSD-7.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.004, required 6, BAYES_00 -15.00, DKIM_SIGNED 0.00, DKIM_VERIFIED -0.00, HOT_NASTY 1.00, MIME_QP_LONG_LINE 1.40, RDNS_DYNAMIC 0.10, SMILEY -0.50) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No X-Mailman-Approved-At: Thu, 13 Dec 2007 12:24:04 +0000 Cc: Yuri , freebsd-hackers@freebsd.org Subject: Re: Linux executable picks up FreeBSD library over linux one and breaks X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Dec 2007 09:08:36 -0000 Quoting Chuck Robey (from Wed, 12 Dec 2007 =20 22:33:18 -0500): > Alexander Leidinger wrote: >> Quoting Chuck Robey (from Mon, 03 Dec 2007 =20 >> 13:30:50 -0500): >> >>> Alexander Leidinger wrote: >>>> Quoting Chuck Robey (from Sun, 02 Dec 2007 =20 >>>> 13:23:33 -0500): >>>> >>>>> You've gotten some good suggestions, but I might add one more, I don't >>>>> think it's been mentioned. I have foound, myself in the last 2 weeks, >>>>> some FreeBSD ports putting in Linux tools, installing stuff in the >>>>> wrong places, like sticking in SYSV libraries in /usr/local/lib instea= d >>>>> of /compat/linux/usr/lib. I verified in that case that the Linux >>>> >>>> If they put the libs directly in /usr/local/lib instead of =20 >>>> /usr/local/lib/, then it is a big =20 >>>> error. But if it is in a subdirectory where no FreeBSD lib =20 >>>> resides, it is ok (the linux browser sets LD_LIBRARY_PATH in the =20 >>>> start script to the right path). >>>> >>>> Have a look how the native browser works, the private libs are =20 >>>> not in ldconfig either and the browser start script sets the =20 >>>> library path for the browser binary. At least it did this the =20 >>>> last time I checked... >>>> >>> >>> Does that mean that all programs needing those libs must have wrapper >>> shells, so as ot implement the LD_LIBRARY_PATH? I know of programs >> >> Yes. For the mozilla stuff it seems to be a design decision of them =20 >> to put the libs in a non-standard path (this is independent from =20 >> the OS). Don't shoot FreeBSD, shoot them if you don't like this. >> >>> that bomb if that's even set at all, and I think it can be a security >>> tool, and I just think that there is no good reason for installing >>> Linux libs outside of the compat tree. There isn't any good reason not >> >> You have 2 differet issue here. One issue is that some =20 >> program(-suites) decide to put their libs into a non-standard =20 >> directory. The other one is that you should not mix libs from linux =20 >> and FreeBSD. >> >>> to use the compat tree, is there? You know, there's a local there too, >>> so you don't even need to be ignoring LOCALBASE, which is something I >>> don't care for ports to do at all. >> >> Even if you have them in LINUXBASE, you could pick up the wrong libs >> depending on the search order of the libs directories and the location >> of the libs. >> >> The big goal is, that an user should not have the need to put >> /compat/linux/... into his path to start a linux program. We can do this >> by putting those linux programs into LOCALBASE (easy, if they don't >> install libs or hide the libs in special dirs), or by putting them into >> LINUXBASE and add a wrapper script to LOCALBASE (not as easy, as you >> have to have more knowledge about pkg-plist in the ports to get the port >> to do the right thing). > > > You have jumped over the issue I wanted to address, at least, it looks > like that to me. It seems like you are telling me why Linux libs need > to be in different dirs, but I did say I understood that. You really > do need to have them in different directories, so that the two > different file types can more easily be administered both by users and > by ldconfig. I am not arguing that, not for an instant, so please read > this following text. > > I am complaining about mixing FreeBSD and non-FreeBSD libs, both of > them in the /usr/local tree. I know that it can do this, but I am > saying that this is an unnecessary complication, and that all Linux > binaries and libraries, etc. should actually go into the /compat/linux > tree instead. As far as possible, our ports tree should not contribute For pure infrastructure ports (like linux-png, linux-gtk, ...) this is =20 already the case. It is "just" the ports which come with end-user =20 applications (or the other way around, ports of end-user applications =20 which come with libs) for which I haven't enforced such a rule. > to the confusion. There are a large host of reasons why this is so, > even some beyond the obvious 2, of needing to help users keep the > separation, and to make keeping the ldconfig stuff separate. There is > also an ugly trend in most linuxes to install everything into /usr, and > not to have any /usr/local at all. This is very easily accomodated > with /compat/linux, but it's a major PITA if Linux stuff must go into > /usr/local. Trying to get the Linux software to give up this silly > bias isn't even an issue, if it was installed into /compat/linux. > > I really like the ability to have different apps, ones that really do > fall in different categories, to install in different areas. Among > other things, this allows one to very easily do a chroot in > /compat/linux. I have tried it, it really works fine, and lets you A chroot into /compat/linux is not supported anymore. We have =20 fall-through cases from /compat/linux/XXX to /XXX where it makes sense =20 (e.g., some config files). This is to make the user experience more pleasant (the linux part =20 behaves the same as the corresponding FreeBSD part, as the config is =20 the same file in the end). If you want to chroot into a linux =20 environment, you should use one of the linux_dist ports (can be =20 installed additionally, as it installs into a different location). > have a really good level of Linux compatibility. We lose that totally > if the Linux and FreeBSD stuff is mixed with a different subdir for > eacy lousy app. > > Let me illustrate this further. A whole lot of apps take this tack: > they create their own little subdir in /usr/local/lib, so that they can > add even more rotten little paths both to the Linux executable path and > the Ldconfig path. This sort of behavior is really crazy to do, but > that's what all those ports authors do, those who must install their > libraries, (their SYSV libs, understand) to /usr/local. > > Above and beyond this, all the applications, (and not just browsers, > every single Linux app that uses stuff with libs installed into > /usr/local) needs to have sh shims to kick them off, so that the > location of the libraries, in their odd spots, can be crafted to work. > All those little sh shims, all because some ports authors can't use > /compat/linux. Isn't it obvious that this is poor behavior? It is not as poor as the alternative (at least the alternative I know =20 about, feel free to come up with a better idea how to handle the =20 following). My goal is that it is easy to start a linux program. If I install =20 e.g., acroread, I just want to type "acroread pdffile" withhout the =20 need to do something else. I don't need to specify the path to it =20 (/compat/linux/.../acroread), and I don't want to add =20 /compat/linux/XXX to my PATH. The last part is very important, as it =20 prevents a lot of foot shooting for endusers. A lot of people can use =20 e.g., acroread, they don't need to be smart to do this, and they don't =20 need to know a lot about unix to do it. But if those people add =20 /compat/linux/... to their path, hell can (and most probably will) =20 break lose. The users get a mixed environment and a lot of strange =20 situations will occur depending on where in their PATH they have the =20 linux paths. Those users will not say that they where too stupid / =20 without enough knowledge to use it, they will say FreeBSD is not =20 userfriendly. To achieve this goal we have 2 possibilities, either we install =20 everything into LINUXBASE and install a wrapper in LOCALBASE, or we =20 install everything in a safe location in LOCALBASE. The first part =20 requires that the maintainers of the linux program play some tricks in =20 their port (plist and/or Makfile). If they fail to do this, it =20 increases the load of portmgr from time to time (build failures on the =20 build cluster). In the second case (install into a safe place in =20 LOCALBASE), portmgr is out of the loop, as if something goes wrong, =20 the port maintainer and/or emulation@ is asked for help, as it is a =20 bug of the port. When I look at the quality of some linux ports (not maintained by =20 emulation@ and before I send improvement suggestions to the =20 maintainer), I think it is better to do it the way we do it currently =20 (installing into a safe place in LOCALBASE). This way it is easier to =20 create a linux port (it is already hard enough for some people to get =20 right as it is). The current way is a compromise between ease of use for users / =20 creation of ports, and the perfect but harder solution. It's based =20 upon experience with updating the infrastructure ports owned by =20 emulation@ and helping users with problems (and having my own problems =20 with the linuxulator myself). > I really wish that ports management would go on the record and make a > definite ruling, that all linux images should install to the > /compat/linux tree. If this would be the case, then nI would myself go In case portmgr does something like this, the rule should include, =20 that end-user applications should contain a wrapper script in =20 LOCALBASE, which allows to start the ported application without the =20 need to add LINUXBASE/... to the PATH to prevent hell on earth (I =20 would say that it is forbidden to tell users in a port to add =20 LINUXBASE to the PATH, but I hope this is not necessary). Note: I =20 still prefer the current way of handling this. Feel free to improve =20 your proposal to keep the same ease of use/porting while getting the =20 benefit of the separation. I'm open for improvement suggestions. > about fixing the horde of software that violates this. I said horde, > and I sure meant it. I don't object that you say "horde". I know about it, I touched 99% of =20 them at least once. :) Bye, Alexander. --=20 In Hollywood, all marriages are happy. It's trying to live together afterwards that causes the problems. =09=09-- Shelley Winters http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137