Currently mozilla has the following in its rules file to do the shlibdeps
___
cd debian && cat $(nspr).shlibs > shlibs.local
env
LD_LIBRARY_PATH=$(CURDIR)/debian/$(nspr)/usr/lib:$(CURDIR)/debian/tmp/usr/lib/mozilla \
dh_shlibdeps -pmozilla -plibnspr4
rm -f debian/shlibs.local
___
libnspr4.shlibs
On Fri, Sep 08, 2000 at 08:28:37PM +0200, Simon Richter wrote:
> On Fri, 8 Sep 2000, Ben Collins wrote:
>
> > > I assume if you have a script which depends on an Architecture: any
> > > or more restrictive Architecture:, you still just go ahead and set
> > > Architecture: all and let the dependenc
On Fri, Sep 08, 2000 at 08:28:37PM +0200, Simon Richter wrote:
> On Fri, 8 Sep 2000, Ben Collins wrote:
>
> > > I assume if you have a script which depends on an Architecture: any
> > > or more restrictive Architecture:, you still just go ahead and set
> > > Architecture: all and let the dependen
On Fri, 8 Sep 2000, Ben Collins wrote:
> > I assume if you have a script which depends on an Architecture: any
> > or more restrictive Architecture:, you still just go ahead and set
> > Architecture: all and let the dependency make it clear which architectures
> > it can work on?
> If you mean,
On Fri, Sep 08, 2000 at 09:50:57AM -0800, Britton wrote:
>
> I assume if you have a script which depends on an Architecture: any
> or more restrictive Architecture:, you still just go ahead and set
> Architecture: all and let the dependency make it clear which architectures
> it can work on?
If
I assume if you have a script which depends on an Architecture: any
or more restrictive Architecture:, you still just go ahead and set
Architecture: all and let the dependency make it clear which architectures
it can work on?
Britton Kerin
On Fri, 8 Sep 2000, Ben Collins wrote:
> > I assume if you have a script which depends on an Architecture: any
> > or more restrictive Architecture:, you still just go ahead and set
> > Architecture: all and let the dependency make it clear which architectures
> > it can work on?
> If you mean,
On Fri, Sep 08, 2000 at 09:50:57AM -0800, Britton wrote:
>
> I assume if you have a script which depends on an Architecture: any
> or more restrictive Architecture:, you still just go ahead and set
> Architecture: all and let the dependency make it clear which architectures
> it can work on?
If
I assume if you have a script which depends on an Architecture: any
or more restrictive Architecture:, you still just go ahead and set
Architecture: all and let the dependency make it clear which architectures
it can work on?
Britton Kerin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with
On Thu, Aug 31, 2000 at 04:21:40PM -0800, Britton wrote:
> I notice that some packages (including one I have recently become the
> maintainer of) have in rules clean a command '-$(MAKE) -i clean' to invoke
> upstream's cleanup, then later dh_clean Makefile. This is fine, except
> packages that use
On Thu, Aug 31, 2000 at 09:15:38PM +0400, Peter Novodvorsky wrote:
> I have source package version X that produces two binary packages. How
> can i make that one bin-package has version X, and another Y != X?
For example:
dh_gencontrol -ppackagex
dh_gencontrol -ppackagey -u"-v1.0"
On Thu, Aug 31, 2000 at 04:21:40PM -0800, Britton wrote:
> I notice that some packages (including one I have recently become the
> maintainer of) have in rules clean a command '-$(MAKE) -i clean' to invoke
> upstream's cleanup, then later dh_clean Makefile. This is fine, except
> packages that us
On Thu, Aug 31, 2000 at 09:15:38PM +0400, Peter Novodvorsky wrote:
> I have source package version X that produces two binary packages. How
> can i make that one bin-package has version X, and another Y != X?
For example:
dh_gencontrol -ppackagex
dh_gencontrol -ppackagey -u"-v1.0
TkMan author insists on using the MANPATH environment variable.
The bottom line is that
* TkMan used to have a variety of ways to set the MANPATH if it
was not already set. The MANPATH is simple to set, is recognized
on all flavors of UNIX and all man-related tools, is eas
14 matches
Mail list logo
