Hi Jonathan, thank you for your explaination. I think your proposal for a compatibility package is very good.
Thanks, Wolfgang On Tue, Nov 15, 2011 at 10:50 PM, Jonathan Nieder <jrnie...@gmail.com> wrote: > Wolfgang Tichy wrote: > >> Thanks for your answer. I think the intel compiler does support the -B >> and -I options. So I think your suggestion would work. However, I am >> not sure if I like this solution. > > It's only a workaround. A fix would involve contacting the Intel > developers to get icc to search the new paths by default. > >> I always loved debian for the fact >> that libraries and include files were in standard places (unlike say >> in redhat based distributions). So it was always easy to compile with >> any compiler. > > Yes, I understand. > >> Moving them to other places seems to complicate things. >> I mean I am no expert on multiarch and guess there are good reasons >> for that. But why can't there be symlinks to the files you need for >> your own architecture in standard places? Would that break something? > > There are two sides to that question: would adding such symlinks be > feasible? And would the resulting behavior of the system be desirable? > > Compatibility symlinks for multiarch: the use case > -------------------------------------------------- > > Let's take the second question first. If /usr/lib and /usr/include > were filled with symlinks to the corresponding architecture-specific > files for the native architecture, there would be some nice benefits: > > - multiarch-unaware compilers would continue to work > - programs hard-coding paths to libraries would continue to work > > On the other hand, binaries and builds for foreign architectures > would be likely to misbehave when libraries for that arch are missing > (/usr/lib/<arch>/foo.so is missing and /usr/lib/foo.so is not). So > for someone using only multiarch-aware programs, the net effect is > negative. > > Compatibility symlinks for multiarch: feasibility > ------------------------------------------------- > > Now the first question. In wheezy, packages that are marked as such > can be installed on multiple architectures at once. So, for example, > I can install the i386 and the amd64 versions of libavcodec at the > same time. > > Which package would get to put a symlink to its library in /usr/lib? > > It's tempting to say "the native one", but it is not always clear > which one that is. In fact, one of the goals of multiarch is to be > able to (gradually) upgrade an i386 system to an amd64 one. At what > point has the native architecture switched? > > A proposal > ---------- > > The above suggests to me a possible way forward. To be clear, I do > not want to work on this; this is just a sketch of one way that people > who do want to work on it could try. > > The idea is that there would be a separate package that installs > compatibility symlinks pointing to /usr/lib/<triplet>/* and > /usr/include/<triplet>/* to help people still using multiarch-unaware > tools. > > Its post-installation script would be a simple script that scans > /usr/lib/<triplet> and /usr/include/<triplet> for added or removed > libraries and updates the corresponding symlinks in /usr/lib and > /usr/include. Using triggers (see [1]) it would ensure that this > script is run for each apt run in which a file is installed to or > removed from /usr/lib/<triplet> or /usr/include/<triplet>. > > This compatibility package could be removed at any time and > multiarch-aware packages would continue to work. > > (Based on an idea from Matthias Klose[2].) > > Of course, I would be even happier to see tools like icc learn about > the new paths. > > Hope that helps, > Jonathan > > [1] /usr/share/doc/dpkg-dev/triggers.txt.gz > [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=40;bug=634821 > >> Thanks, >> Wolfgang >> >> PS: I do not mean to complain. I think Debian is great and I am >> grateful for the job you maintainers do. I only write because I like >> Debian, and thought this might be helpful... > -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
