On Fri, 6 Oct 2000 [EMAIL PROTECTED] wrote:
> If you want to use rpath then you might want to check it with
> somebody with experience in security (Debian security team?),
rpath has some advantages in this case over hardwiring the paths into the
executable (for example, you can add paths at runti
On Fri, 6 Oct 2000 [EMAIL PROTECTED] wrote:
> If you want to use rpath then you might want to check it with
> somebody with experience in security (Debian security team?),
rpath has some advantages in this case over hardwiring the paths into the
executable (for example, you can add paths at runt
If you want to use rpath then you might want to check it with
somebody with experience in security (Debian security team?),
I think one of the arguments was about security. I may be
totally off here, but IIRC rpath also checks an environment
variable and this is considered very insecure.
HTH
t.aa
If you want to use rpath then you might want to check it with
somebody with experience in security (Debian security team?),
I think one of the arguments was about security. I may be
totally off here, but IIRC rpath also checks an environment
variable and this is considered very insecure.
HTH
t.a
On Thu, 5 Oct 2000, Rick Younie wrote:
> Yeah, I talked to the Regina maintainer about this. He's happier
> leaving the libs in /usr/lib rather than using rpath so I guess
> he'd feel the same about modifying ld.so.conf.
Another option for loadable modules would be to dlopen() them with the
full
On Thu, 5 Oct 2000, Rick Younie wrote:
> Yeah, I talked to the Regina maintainer about this. He's happier
> leaving the libs in /usr/lib rather than using rpath so I guess
> he'd feel the same about modifying ld.so.conf.
Another option for loadable modules would be to dlopen() them with the
ful
> > Another thing you could do is to stuck the libs in a
> subdirectory and have
> > your postinst and postrm edit /etc/ld.so.conf. That sounds like the
> > traditional way to me, but then that was before rpath...
>
> It's a little trickier than the way xaw3d handled it though. A
> half-dozen pa
> > Another thing you could do is to stuck the libs in a
> subdirectory and have
> > your postinst and postrm edit /etc/ld.so.conf. That sounds like the
> > traditional way to me, but then that was before rpath...
>
> It's a little trickier than the way xaw3d handled it though. A
> half-dozen p
> > > 1. I see no mention on rpath in the policy manual (grepping through
all the
> > > .html files) yet lintian issues a warning about it. I'm asking because
I'm
> > > packaging something that uses rpath heavily.
>
> > rpath hardcodes an item's location. If this item later moves,
everything using
> > > 1. I see no mention on rpath in the policy manual (grepping through
all the
> > > .html files) yet lintian issues a warning about it. I'm asking because
I'm
> > > packaging something that uses rpath heavily.
>
> > rpath hardcodes an item's location. If this item later moves,
everything usin
> I was wondering about rpath as well. I maintain a couple
> packages that drop 5 function libs for regina-rexx in /usr/lib.
> There are probably another 6-8 that someone might package.
> /usr/lib could soon be as bad as /var/lib/dpkg/info. You can
> pretty much go for coffee on your first 'dpkg
Simon Richter wrote:
> On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
>
>> rpath hardcodes an item's location. If this item later moves,
>> everything using it gets confused. rpath is generally frowned
>> upon.
>
> rpath adds additional path elements to the search list. Libraries are
> still fou
> I was wondering about rpath as well. I maintain a couple
> packages that drop 5 function libs for regina-rexx in /usr/lib.
> There are probably another 6-8 that someone might package.
> /usr/lib could soon be as bad as /var/lib/dpkg/info. You can
> pretty much go for coffee on your first 'dpkg
Simon Richter wrote:
> On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
>
>> rpath hardcodes an item's location. If this item later moves,
>> everything using it gets confused. rpath is generally frowned
>> upon.
>
> rpath adds additional path elements to the search list. Libraries are
> still fo
>
> I could be wrong, but it seems to me like you might not want to define
> REENTRANT if your library isn't. There are many many libraries that are
> not, one way or another.
>
Policy states a lib in Debian should be compiled with REENTRANT. So if this
fails, he can file a bug.
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > So, let's say the package is build with --disable-threads. I should still
> > use -D_REENTRANT for the libraries since even though they don't use threads
> > themselves they may be used by applications that do use threads. And then I
> > should n
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > 1. I see no mention on rpath in the policy manual (grepping through all the
> > .html files) yet lintian issues a warning about it. I'm asking because I'm
> > packaging something that uses rpath heavily.
> rpath hardcodes an item's location. If
>
> So, let's say the package is build with --disable-threads. I should still
> use -D_REENTRANT for the libraries since even though they don't use threads
> themselves they may be used by applications that do use threads. And then I
> should not use -D_REENTRANT for the applications themselves si
> > 1. I see no mention on rpath in the policy manual (grepping
> through all the
> > .html files) yet lintian issues a warning about it. I'm
> asking because I'm
> > packaging something that uses rpath heavily.
> >
> rpath hardcodes an item's location. If this item later
> moves, everything u
On 03-Oct-2000 Yves Arrouye wrote:
> Hi,
>
> I was browsing policy to familiarize myself with it again, and I have two
> questions:
>
> 1. I see no mention on rpath in the policy manual (grepping through all the
> .html files) yet lintian issues a warning about it. I'm asking because I'm
> packa
>
> I could be wrong, but it seems to me like you might not want to define
> REENTRANT if your library isn't. There are many many libraries that are
> not, one way or another.
>
Policy states a lib in Debian should be compiled with REENTRANT. So if this
fails, he can file a bug.
--
To UNS
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > So, let's say the package is build with --disable-threads. I should still
> > use -D_REENTRANT for the libraries since even though they don't use threads
> > themselves they may be used by applications that do use threads. And then I
> > should
On Tue, 3 Oct 2000, Sean 'Shaleh' Perry wrote:
> > 1. I see no mention on rpath in the policy manual (grepping through all the
> > .html files) yet lintian issues a warning about it. I'm asking because I'm
> > packaging something that uses rpath heavily.
> rpath hardcodes an item's location. If
>
> So, let's say the package is build with --disable-threads. I should still
> use -D_REENTRANT for the libraries since even though they don't use threads
> themselves they may be used by applications that do use threads. And then I
> should not use -D_REENTRANT for the applications themselves s
> > 1. I see no mention on rpath in the policy manual (grepping
> through all the
> > .html files) yet lintian issues a warning about it. I'm
> asking because I'm
> > packaging something that uses rpath heavily.
> >
> rpath hardcodes an item's location. If this item later
> moves, everything
On 03-Oct-2000 Yves Arrouye wrote:
> Hi,
>
> I was browsing policy to familiarize myself with it again, and I have two
> questions:
>
> 1. I see no mention on rpath in the policy manual (grepping through all the
> .html files) yet lintian issues a warning about it. I'm asking because I'm
> pack
26 matches
Mail list logo
