Quoting Chuck Robey <[EMAIL PROTECTED]> (from Wed, 12 Dec 2007
22:33:18 -0500):
Alexander Leidinger wrote:
Quoting Chuck Robey <[EMAIL PROTECTED]> (from Mon, 03 Dec 2007
13:30:50 -0500):
Alexander Leidinger wrote:
Quoting Chuck Robey <[EMAIL PROTECTED]> (from Sun, 02 Dec 2007
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 instead
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
/usr/local/lib/<linux_port_specific_directory>, then it is a big
error. But if it is in a subdirectory where no FreeBSD lib
resides, it is ok (the linux browser sets LD_LIBRARY_PATH in the
start script to the right path).
Have a look how the native browser works, the private libs are
not in ldconfig either and the browser start script sets the
library path for the browser binary. At least it did this the
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
to put the libs in a non-standard path (this is independent from
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
program(-suites) decide to put their libs into a non-standard
directory. The other one is that you should not mix libs from linux
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
already the case. It is "just" the ports which come with end-user
applications (or the other way around, ports of end-user applications
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
fall-through cases from /compat/linux/XXX to /XXX where it makes sense
(e.g., some config files).
This is to make the user experience more pleasant (the linux part
behaves the same as the corresponding FreeBSD part, as the config is
the same file in the end). If you want to chroot into a linux
environment, you should use one of the linux_dist ports (can be
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
about, feel free to come up with a better idea how to handle the
following).
My goal is that it is easy to start a linux program. If I install
e.g., acroread, I just want to type "acroread pdffile" withhout the
need to do something else. I don't need to specify the path to it
(/compat/linux/.../acroread), and I don't want to add
/compat/linux/XXX to my PATH. The last part is very important, as it
prevents a lot of foot shooting for endusers. A lot of people can use
e.g., acroread, they don't need to be smart to do this, and they don't
need to know a lot about unix to do it. But if those people add
/compat/linux/... to their path, hell can (and most probably will)
break lose. The users get a mixed environment and a lot of strange
situations will occur depending on where in their PATH they have the
linux paths. Those users will not say that they where too stupid /
without enough knowledge to use it, they will say FreeBSD is not
userfriendly.
To achieve this goal we have 2 possibilities, either we install
everything into LINUXBASE and install a wrapper in LOCALBASE, or we
install everything in a safe location in LOCALBASE. The first part
requires that the maintainers of the linux program play some tricks in
their port (plist and/or Makfile). If they fail to do this, it
increases the load of portmgr from time to time (build failures on the
build cluster). In the second case (install into a safe place in
LOCALBASE), portmgr is out of the loop, as if something goes wrong,
the port maintainer and/or emulation@ is asked for help, as it is a
bug of the port.
When I look at the quality of some linux ports (not maintained by
emulation@ and before I send improvement suggestions to the
maintainer), I think it is better to do it the way we do it currently
(installing into a safe place in LOCALBASE). This way it is easier to
create a linux port (it is already hard enough for some people to get
right as it is).
The current way is a compromise between ease of use for users /
creation of ports, and the perfect but harder solution. It's based
upon experience with updating the infrastructure ports owned by
emulation@ and helping users with problems (and having my own problems
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,
that end-user applications should contain a wrapper script in
LOCALBASE, which allows to start the ported application without the
need to add LINUXBASE/... to the PATH to prevent hell on earth (I
would say that it is forbidden to tell users in a port to add
LINUXBASE to the PATH, but I hope this is not necessary). Note: I
still prefer the current way of handling this. Feel free to improve
your proposal to keep the same ease of use/porting while getting the
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
them at least once. :)
Bye,
Alexander.
--
In Hollywood, all marriages are happy. It's trying to live together
afterwards that causes the problems.
-- Shelley Winters
http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
