Date: Sun, 13 Jan 2008 08:25:15 -0600 From: eculp <eculp@encontacto.net> To: freebsd-ports@freebsd.org Subject: Another question based on: Re: HOW-TO get Flash7 working! Message-ID: <20080113082515.19316v8x3pbs3tcs@intranet.encontacto.net> In-Reply-To: <20080112213747.443a4833@deskjail> References: <64c038660801040516u5c42a6cpadb475ad67fb4730@mail.gmail.com> <20080104174955.52aa33fd@gumby.homeunix.com> <64c038660801041029t1a9662bayed3ca02fd46c7ece@mail.gmail.com> <64c038660801041226k1d350bc6p727e4666ea295727@mail.gmail.com> <477FFE14.1010704@monkeybrains.net> <477FFF63.50004@gmail.com> <47801D54.8050709@gmail.com> <47803E3F.2080005@monkeybrains.net> <47804901.6090007@gmail.com> <4786BF45.8030602@monkeybrains.net> <4786CEDC.3050009@chuckr.org> <20080111170711.t6wxj1bc68cgwwk4@webmail.leidinger.net> <4787E597.9040902@chuckr.org> <20080112213747.443a4833@deskjail>
next in thread | previous in thread | raw e-mail | index | archive | help
The dialog at the end of this email is becoming a bit more =20 philosophical than I need right now ;). Is there an "accepted" or reasonably so, sure-fire way to get linux =20 flash[79] working in Prerelease or in current? If so, would you =20 please share how you did it on this list? Flash is becoming more dominate daily and there are many sites that =20 are basically unusable without it. Some banking, telco, etc. sites, =20 etc. That are difficult if not impossible too use for account access =20 without flash and don't pay much attention to end user requests based =20 on the installed base of Flash[89]. That brings up another detail, =20 many sites now require Flash[89] even though they don't actually need =20 it probably to impress their customers with their being on the =20 technological, bleeding edge. Thanks, Chuck, for getting this started and for finding a solution =20 that may or may not be appropriate for all. I would personally like =20 to try what you have done with flash9 if it is stable for you and if =20 you would be so kind as to document a bit clearer how to do it. Thanks to all, ed Quoting Alexander Leidinger <Alexander@Leidinger.net>: > Quoting Chuck Robey <chuckr@chuckr.org> (Fri, 11 Jan 2008 16:54:31 -0500): > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Alexander Leidinger wrote: >> > Quoting Chuck Robey <chuckr@chuckr.org> (from Thu, 10 Jan 2008 21:05:16 >> > -0500): >> > >> >> I actually got the linux flash9 working. Why didn't I post it, put in= a >> >> patch? Because one of the main reasons that it doesn't work now is th= e >> >> insane way that much Linux libraries are installed. If folks would ho= nor >> > >> > Would you mind telling us how, so that we understand the problem? >> > >> >> hier(7) then all linux libs would go into /usr/compat/usr/lib, but >> >> instead, many linux ports (including browsers, believe me) install int= o >> >> $(PREFIX)/lib/libsubdir. This means every single linux app that uses >> >> linux >> >> libs hsa to be run with a shell wrapper, artificially extending the >> >> LD_LIBRARY_PATH. Since no porter of an app installing libs knows all = the >> >> ports that might use their libs, random breakages are the rule of the >> >> day, >> >> to say nothing of the egregious harm to security this kind of strategy >> >> causes. It's a big reason why the flash things don't work. Want proo= f? >> >> Go use the linux ldd to see just how long the list of libraries is, th= at >> >> those extensions use, then you'll begin to see. Not all those libs a= re >> >> browser products, either. Have fun trying to get a wrapper to work >> >> there. >> >> >> >> I volunteered to fix this situation all myself, if only the ports >> >> management would give me written agreement that the strategy I decry >> >> is in >> >> fact bad software practice, so that I may point to that document to po= rt >> >> authors, when I ask for permission to edit their work. Ports manageme= nt >> >> hasn't seen fit to reply, or at least, I haven't seen it if they did. = I >> >> don't intend to force anyone, but without having ports mangement >> >> backing, I >> >> am NOT going to have this argument with every porter, no way. I tried >> >> that >> >> once, and at least one fellow told me he thought that requiring every >> >> linux >> >> application to have it's own wrapper was the "cleaner" way to go. >> >> Huh, if >> >> that's so, then I guess I should be stopped anyhow. You think that wa= y? >> > >> > I think you are referring to me here. I think the important part to >> > understand my opinion to install end-user applications into PREFIX >> > instead of LINUXPREFIX (note: linux library ports _have_ to go to >> > LINUXBASE) is missing here. >> >> In fact, I have never been at all good at remembering names, to the point >> that I no longer even try. I haven't the faintest idea (even now) if it >> was you or not. If it pleases you, though, that's fine, assume away. I >> don't think I was insulting, I have made enough of an ass of myself in th= e >> past to realize the folly of being sarcastic (it always comes back to bit= e >> you). > > I didn't understand it as insulting. > >> > No user shall have subdirs of LINUXPREFIX in his path. This would open >> > up Pandorra's box. >> >> OK, need to stop you here. I don't know what that LINUXPREFIX item is. = I > > It was either my mispelling of LINUXBASE, or my failed try to make a > distinction between the user chosen prefix for two different > "management domains". Chose the error you like more. ;-) > >> just grepped for it in /usr/ports subdirs Mk, emulators, and www (recursi= ve >> one), and even did an apropos. I did a bit of googling and found a >> LINUXPREFIX in some Linux docs, is that the one you're referring to? >> What's it mean, how's it used? >> >> Regardless, please, could you explain why it would open up Pandora's Box? >> Maybe if I could have a better handle on what it is, I might not ask that >> question, but I can't, so I'm asking. > > If an user has the bin directories in the LINUXBASE in his path > - he may accidentally execute linux programs when FreeBSD programs > may be required > - a configure run may detect linux things and enable stuff which > is not valid for FreeBSD > - ... (I don't remember everything by heart, and I'm too lazy > currently to try to reverse engineer all of them in my brain, > but you get the big picture of the bad stuff which can happen) > > All of this may be confusing, specially for newbies. And if we require > that users add some LINUXBASE directories to their PATH (which means > manual activity to be able to run a program, where the current approach > doesn't need this and has not the above drawbacks) by default, even > newbies do that, and they will not be able to handle this situation and > will throw FreeBSD away. > >> One item that some might not know: most unixes have a strong bias towards >> installing everything into /usr/bin or /usr/lib. Many Linux boxes don't >> even have a /usr/local, or opt, or whatever. Much Linux software makes t= he >> assumption that it's using a prefix of /usr. I hate this myself, I MUCH >> more like FreeBSD's way of doing things, but I can have my cake and eat i= t >> too, if Linux software is installed into /compat/linux/usr/bin (and lib, >> etc), I get the separation as far as FreeBSD is concerned, but Linux >> software is fooled into obeying their abhorrent lack of separation. =20 >> Real nice. >> >> [Man, your mail is huge, I would have preferred to make it decide things = in >> smaller bits, but I guess not.] Continuing ... >> >> > >> > A clean way to achieve this is to have something in prefix which calls >> > the linux program. This can be a symlink or a wrapper in PREFIX. If you >> > install parts of a port into LINUXPREFIX and a link/wrapper in PREFIX >> > (or more generic: if you have 2 different prefixes in a port), you have >> > to do some ports-magic. If you install the port in a sub-directory in >> > PREFIX and add a wrapper in the PREFIX/bin, you don't have to do >> > ports-magic. >> >> OK. Ab initio, I have always felt that using wrappers was a tacky way t= o >> do things. Not that it wasn't sometimes the only available way to go, bu= t > > It would be nice to do it without the wrapper, but as I already said, > the current situation looks to me as the most pragmatic one. And as the > linuxulator in the kernel is a wrapper of some kind itself, I prefer to > not say bad things about wrappers... ;) > >> certainly to be avoided. I also have always felt that screwing with >> LD_LIBRARY_PATH, as your wrappers would need to do, is a security problem= , > > I fail to see how it is a security problem, when the wrapper sets > LD_LIBRARY_PATH. You can set it yourself and give the application some > "wrong" stuff, but if we assume the wrapper in the port is not a trojan > horse but sets the LD_LIBRARY_PATH correctly, then it should be fine. > Depending on the concrete situation I may agree upon the security > problem point of view, but for this I need to know the concrete > situation. > >> which again might sometimes be the best way to go, but not ever the first >> choice. This is only part of my argument, though (I would be embarrassed >> if my argument was only based upon my prejudices). >> >> The larger real problem is, some ports install libs, and do not know what >> possible executables might need to have their wrappers adjusted. Also, >> some items are difficult to use any wrappers on at all. As an example, t= he >> flash9 plugin needed a linux lib, libdl.so (I think it was .so.2). If I >> wanted to be complete, it really needed about twenty different libraries, >> but libdl.so will serve as an example well enough). It had been installe= d >> in some subdir of /usr/local/lib. I couldn't get a wrapper to work in > > As Boris already commented, it seems some other port is interfering > here, or something is broken on your end. Please use pkg_which to > investigate which port installed it there, so that we can have a look > at this port. > >> that case, and I wasn't going to bork up my linux LD_LIBRARY_PATH with >> about half a dozen locations (which do change occaisonally). Trying to d= o >> all the work of maintaining that wrapper would have made the task nearly >> impossible, so I decided to just copy libs to >> /usr/compat/usr/linux/usr/lib, and it was immediately recognized. I went >> about doing an linux ldd on the plugin, then moving libs and making sure >> with the linux ldd that the plugin was happy once I'd moved the libs. >> There were one or two that needed to be in a subdir of the browser dir >> itself, but mostly, putting it in the compat path worked, and once I was >> finished, flash9 just worked ok. > > It needs careful investigation which ports install those libs there and > why. Maybe something is wrong, maybe not. It would help if you list the > libs which you think are installed incorrectly together with the ports > which installed them. We can have a look at them then and decide how > the situation can be improved. > >> Making a wrapper for the flash9, even if you could coax the browser to >> accept the plugin with a wrapper around it, would not be much of a fun >> task, and the people who put the libs in place, they don't have to help >> you, because you have told them they can put their libs any darn place th= ey >> please. > > While it is possible to make a wrapper around dynamic libs (with the > help of /etc/libmap.conf), a solution without it is preferred. > >> Another really nice fallout from putting things into the compat structure >> is that chroots now work very nicely to make you an extremely compatible >> linux arch. Can't do that with having everything installed all over. > > Sorry to disappoint you, but the linux_base ports are not designed for > this. We rely on some fallthrough to the FreeBSD root directory for > some config files which we have at the same location than linux and are > syntactically compatible. > > If you want a linux base system to chroot into, you should install one > of the linux_dist ports. > >> If you could please, in answering this email, explain your "Pandora's Box= " >> comment, and also explain why installing hard to maintain wrappers is >> better than the way that Linux itself does it, I'd appreciate that. I > > Linux can do it without wrappers, as it hasn't to emulate a foreign > API. As we have to do this, we sometimes have to use wrappers. > >> can't see why, and tossing it off with a tagline like "opening Pandora's >> Box" is cheating, although I can see, can understand why you did it, >> explaining this long argument is tedious, I grant you that. Still, you >> opened the box ... > > If you have some more questions, just ask. > > Bye, > Alexander. > > -- > Professor: Some say I'm robbing the cradle but I say she's robbing =20 > the grave. > http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 > http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137 > _______________________________________________ > freebsd-ports@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ports > To unsubscribe, send any mail to "freebsd-ports-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080113082515.19316v8x3pbs3tcs>