Date: Thu, 13 Dec 2007 10:08:21 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Chuck Robey <chuckr@chuckr.org> Cc: Yuri <yuri@rawbw.com>, freebsd-hackers@freebsd.org Subject: Re: Linux executable picks up FreeBSD library over linux one and breaks Message-ID: <20071213100821.bet532peog8g488s@webmail.leidinger.net> In-Reply-To: <4760A7FE.9070409@chuckr.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Chuck Robey <chuckr@chuckr.org> (from Wed, 12 Dec 2007 =20 22:33:18 -0500): > Alexander Leidinger wrote: >> Quoting Chuck Robey <chuckr@chuckr.org> (from Mon, 03 Dec 2007 =20 >> 13:30:50 -0500): >> >>> Alexander Leidinger wrote: >>>> Quoting Chuck Robey <chuckr@chuckr.org> (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/<linux_port_specific_directory>, 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071213100821.bet532peog8g488s>