On Thu, 2011-09-15 at 13:01 -0400, Christopher J. PeBenito wrote:
> On 09/15/11 08:53, Guido Trentalancia wrote:
> > On Thu, 2011-09-15 at 08:22 -0400, Christopher J. PeBenito wrote:
> >> On 09/15/11 08:16, Guido Trentalancia wrote:
> >>> On Thu, 2011-09-15 at 08:01 -0400, Christopher J. PeBenito wrote:
> >>>> On 09/14/11 16:21, Eric Paris wrote:
> >>>>> On Wed, 2011-09-14 at 15:18 -0400, Stephen Smalley wrote:
> >>>>>> On Wed, 2011-09-14 at 14:50 -0400, Eric Paris wrote:
> >>>>>>> At the moment we create a symlink:
> >>>>>>>
> >>>>>>> /usr/lib/libselinux.so -> ../../lib/libselinux.so.1
> >>>>>>>
> >>>>>>> This works if (and only if) $SHLIBDIR and $LIBDIR are different only by
> >>>>>>> ../../. Instead create a symlink from
> >>>>>>>
> >>>>>>> $LIBDIR/libselinux.so->$SHLIBDIR/libselinux.so.1
> >>>>>>>
> >>>>>>> Thus it works no matter what values one might use for LIBDIR and
> >>>>>>> SHLIBDIR.
> >>>>>>
> >>>>>> I'm not sure this works the way you would want. Consider rpm build of
> >>>>>> libselinux - it does:
> >>>>>> make DESTDIR="%{buildroot}" LIBDIR="%{buildroot}%{_libdir}"
> >>>>>> SHLIBDIR="%{buildroot}/%{_lib}" BINDIR="%{buildroot}%{_sbindir}" install
> >>>>>>
> >>>>>> And then rpm collects up the files into the package.
> >>>>>> But if the symlink encodes the full pathname used at make install time,
> >>>>>> then it will be wrong on the final system when the rpm is installed.
> >>>>>> Haven't actually tested that theory, but I think it is true. Welcome to
> >>>>>> hell.
> >>>>>
> >>>>> error: Symlink points to BuildRoot: /usr/lib64/libselinux.so
> >>>>> -> /root/rpmbuild/BUILDROOT/libselinux-2.1.5-4.fc16.1.eparis.x86_64/lib64/libselinux.so.1
> >>>>>
> >>>>> GRRRRRR. Every other package I see with similar symlinks seems to be
> >>>>> an autoconf package and I can't understand how they work. What we have
> >>>>> isn't right, but I don't know how to fix it....
> >>>>
> >>>> Its easy. The makefile needs to be tweaked so you don't have to specify %{buildroot} as part of the LIBDIR, SHLIBDIR, and BINDIR variables. Then when you use those variables, you prepend DESTDIR as necessary. So if you have usages like
> >>>>
> >>>> install foo $(BINDIR)
> >>>>
> >>>> it turns into
> >>>>
> >>>> install foo $(DESTDIR)(BINDIR)
> >>>>
> >>>> Then when you have your symlink you can do
> >>>>
> >>>> ln -s $(SHLIBDIR)/bar.so.1 $(DESTDIR)$(SHLIBDIR)/bar.so
> >>>
> >>> Yes, this is even better, although $(DESTDIR) is not necessary in the
> >>> target, as SHLIBDIR already includes (begins with) DESTDIR:
> >>>
> >>> ln -sf $(SHLIBDIR)/$(LIBSO) $(SHLIBDIR)/$(TARGET)
> >>
> >> I think you're missing the point. I said you need to stop specifying $(DESTDIR) as part of $(SHLIBDIR). Otherwise you get the broken symlinks that Eric talks about above.
> >
> > In any case, I think it then probably ends up taking more characters
> > than using pushd/popd.
>
> Perhaps it does. I'd argue that its much clearer, thus more maintainable than pushd/popd.
Go on then.
echo "pushd \$(LIBDIR) ; popdpushd \$(SHLIBDIR) ; popd" | wc -m
47
What's the alternative ?
Guido
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
