Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer , 2016-07-05, 21:24: First off, many thanks again for that script. Unfortunately it fails in Ubuntu (see #827770): ./debian/scripts/sonames2elf libcups.so.2 libdbus-1.so.3 libfontconfig.so.1 libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.8 libncurses.so.5 libodbc.so.2 libopenal.so.1 libOSMesa.so.8 libpng16.so.16 libtiff.so.5 libX11.so.6 libXcomposite.so.1 libXcursor.so.1 libXext.so.6 libXi.so.6 libXinerama.so.1 libXrandr.so.2 libXrender.so.1 libxslt.so.1 libXxf86vm.so.1 > debian/tmp/elf.recommends /usr/bin/ld: cannot find libGL.so.1 collect2: error: ld returned 1 exit status debian/rules:153: recipe for target 'override_dh_shlibdeps' failed In Ubuntu libGL.so.1 is in /usr/lib//mesa/. Ugh. :-\ This is not a problem for normally linking with -lGL because the libGL.so symlink lives directly in /usr/lib//. It's also not a problem at runtime, because /usr/lib//mesa/ is included in /etc/ld.so.conf.d/_GL.conf. But it does break sonames2elf, because ld(1) doesn't pay attention to /etc/ld.so.conf*. As a work-around, changing "libGL.so.1" to "libGL.so" in the sonames2elf command-line seems to do the trick. (You may want to implement extra check to ensure that the linker found exactly the same SONAME as it should.) -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
On 28.05.2016 12:30, Jakub Wilk wrote: > * Jens Reyer , 2016-05-27, 20:17: >> I think I have it working now in wine to automatically generate a list >> of runtime dependencies. I based it on Jakub's suggestions, however I >> didn't go for creating a "dependency binary". >> >> For one I did get results this way, but unfortunately I neither really >> know python nor perl which is usually used in wine packaging, in order >> to cleanly implement it there. > > I've attached shell implementation of SONAMEs-to-ELF converter. First off, many thanks again for that script. Unfortunately it fails in Ubuntu (see #827770): ./debian/scripts/sonames2elf libcups.so.2 libdbus-1.so.3 libfontconfig.so.1 libfreetype.so.6 libGL.so.1 libgnutls.so.30 libgsm.so.1 libjpeg.so.8 libncurses.so.5 libodbc.so.2 libopenal.so.1 libOSMesa.so.8 libpng16.so.16 libtiff.so.5 libX11.so.6 libXcomposite.so.1 libXcursor.so.1 libXext.so.6 libXi.so.6 libXinerama.so.1 libXrandr.so.2 libXrender.so.1 libxslt.so.1 libXxf86vm.so.1 > debian/tmp/elf.recommends /usr/bin/ld: cannot find libGL.so.1 collect2: error: ld returned 1 exit status debian/rules:153: recipe for target 'override_dh_shlibdeps' failed In Ubuntu libGL.so.1 is in /usr/lib//mesa/. However this does not cause issues for other Debian packages for finding it (probably by looking at /etc/ld.so.conf). I assume one could explicitly specify the rpath in sonames2elf, but do you have any idea how to solve this generically/why this doesn't work? Greets jre
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
On 05/28/2016 07:17 AM, Paul Wise wrote: > On Sat, May 28, 2016 at 2:17 AM, Jens Reyer wrote: > >> Then (instead of creating a binary linking to the required >> libraries and running dpkg-shlibdeps on this) I replicate things >> from dpkg-shlibdeps(1) to identify the library package names for >> these sonames: > > I wonder if the best solution would be to allow dpkg-shlibdeps to > accept a list of SONAMEs instead of getting that from an ELF file. > Then you could do something like this: > > dpkg-shlibdeps -pdlopen -dRecommends -alibc.so.6 > > Until that is available it seems to me that Jakub Wilk's method of > generating an ELF binary with NEEDED entries for the relevant SONAMEs > is much simpler and less error prone than essentially reimplementing > dpkg-shlibdeps. A modification to the upstream build system could > probably auto-generate the ELF binary and once you have the ELF > binary, you can just do this: > > override_dh_shlibdeps: > dpkg-shlibdeps -pdlopen -dRecommends -etheelfbinary > dh_shlibdeps Thanks! Turns out your suggestion for dpkg-shlibdeps has already been requested: #596715 (dpkg-shlibdeps: Please allow to manually add library dependencies via shlibdeps) #548463 (dpkg-shlibdeps: Please provide a method to compute dependencies for non-elf) Greets jre
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer , 2016-05-29, 17:37: Should I put your coyright and the MIT/X11 (BSD like) license in the script, as seen in dctypes2elf? Yes, please do. -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
On 05/28/2016 12:30 PM, Jakub Wilk wrote: > * Jens Reyer , 2016-05-27, 20:17: >> I think I have it working now in wine to automatically generate a list >> of runtime dependencies. I based it on Jakub's suggestions, however I >> didn't go for creating a "dependency binary". >> >> For one I did get results this way, but unfortunately I neither really >> know python nor perl which is usually used in wine packaging, in order >> to cleanly implement it there. > > I've attached shell implementation of SONAMEs-to-ELF converter. > >> sonames=$(shell grep "^\#define SONAME_" include/config.h | cut -d\" >> -f2) >> paths=/usr /usr/lib /lib/$(shell dpkg-architecture >> -qDEB_HOST_MULTIARCH) /usr/lib/$(shell dpkg-architecture >> -qDEB_HOST_MULTIARCH) >> dlopenRecommends=$(shell \ >>for soname in $(sonames); do \ >>for path in $(paths); do \ >>file=$$(echo $$path/$$soname | sed "s|//|/|g"); \ >>[ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\) >> */\\1,/" && break || true; \ >>done; \ >>done) Massive thanks again, Jakub, that helped a lot to understand and implement. As additional benefit I now also get alternative dependencies (libgl1-mesa-glx|libgl1). I implemented it similar to what Paul suggested. Should I put your coyright and the MIT/X11 (BSD like) license in the script, as seen in dctypes2elf? Wine itself is LGPL-2.1+ licensed. Greets jre
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
Hi Jens! >- first find the library file on the system (looking in some > hardcoded directories), I'm really sure it won't add any value to your current solution, but you might consider asking ld or whatever the list of search paths http://stackoverflow.com/questions/9922949/how-to-print-the-ldlinker-search-path maybe some of your libraries have no-really standard path locations? not sure, G.
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer , 2016-05-27, 20:17: I think I have it working now in wine to automatically generate a list of runtime dependencies. I based it on Jakub's suggestions, however I didn't go for creating a "dependency binary". For one I did get results this way, but unfortunately I neither really know python nor perl which is usually used in wine packaging, in order to cleanly implement it there. I've attached shell implementation of SONAMEs-to-ELF converter. sonames=$(shell grep "^\#define SONAME_" include/config.h | cut -d\" -f2) paths=/usr /usr/lib /lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) /usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH) dlopenRecommends=$(shell \ for soname in $(sonames); do \ for path in $(paths); do \ file=$$(echo $$path/$$soname | sed "s|//|/|g"); \ [ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\) */\\1,/" && break || true; \ done; \ done) The problem with $(shell) constructs is that they ignore errors. Please avoid putting complicated code in them. -- Jakub Wilk #!/bin/sh set -e -u if [ $# = 0 ] || tty <&1 >/dev/null then printf 'Usage: %s SONAME... > ELF\n' "$0" exit 1 fi tmpdir=$(mktemp -d -t sonames2elf.XX) cd "$tmpdir" printf 'INPUT(%s)\n' "$@" > libeverything.so gcc -shared -nostdlib -Wl,--no-as-needed -L. -leverything -o elf cat elf rm -rf "$tmpdir"
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
On Sat, May 28, 2016 at 2:17 AM, Jens Reyer wrote: > Then (instead of creating a binary linking to the required > libraries and running dpkg-shlibdeps on this) I replicate things > from dpkg-shlibdeps(1) to identify the library package names for > these sonames: I wonder if the best solution would be to allow dpkg-shlibdeps to accept a list of SONAMEs instead of getting that from an ELF file. Then you could do something like this: dpkg-shlibdeps -pdlopen -dRecommends -alibc.so.6 Until that is available it seems to me that Jakub Wilk's method of generating an ELF binary with NEEDED entries for the relevant SONAMEs is much simpler and less error prone than essentially reimplementing dpkg-shlibdeps. A modification to the upstream build system could probably auto-generate the ELF binary and once you have the ELF binary, you can just do this: override_dh_shlibdeps: dpkg-shlibdeps -pdlopen -dRecommends -etheelfbinary dh_shlibdeps -- bye, pabs https://wiki.debian.org/PaulWise
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
On 05/19/2016 05:53 PM, Jakub Wilk wrote:
> * Jens Reyer , 2016-05-19, 16:57:
>> First off, I'm not sure about every single dependency if it is needed
>> at all.
>
> Quick grep over the *.dll.so indeed shows that they use a bunch of
> libraries you mentioned:
[...]
> I guess a better method of obtaining the list of used shared libraries
> is to grep for "SONAME_" in include/config.h (after it was created by
> the configure script).
>
> Once you have the list of needed shlibs, the simplest way to compute
> package dependency is to create an ELF that depends on all of them, and
> then use dpkg-shlibdeps against it.
>
> You can steal the idea of how to create such ELF here:
> https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf
Thanks a lot Jakub and Gianfranco!
I think I have it working now in wine to automatically generate a
list of runtime dependencies. I based it on Jakub's suggestions,
however I didn't go for creating a "dependency binary".
For one I did get results this way, but unfortunately I neither
really know python nor perl which is usually used in wine
packaging, in order to cleanly implement it there. Generally more
relevant however, since I probably found a Makefile/shell
solution, I'd like to keep it as simple as possible.
I chose to (as suggested) first check for all sonames in
include/config.h after configure. This gives similar results as
grep'ing for *.so (and a lot more than for *.dll.so). The
differences are only for shlibs, which are not relevant here.
Then (instead of creating a binary linking to the required
libraries and running dpkg-shlibdeps on this) I replicate things
from dpkg-shlibdeps(1) to identify the library package names for
these sonames:
- first find the library file on the system (looking in some
hardcoded directories),
- then use "dpkg -S library-file" to lookup the package providing
the library.
I put these library names in a custom substvar
${dlopen:Recommends}, and pass it on with dh_gencontrol. Done.
I'd like to hear your opinion on this, for now my own thoughts:
- As long as there are no specific symbols to work with, we don't
know if we'd need a version constraint (I think this was
Gianfranco's point). But since I'm only looking for the sonames,
we can't profit from using a sophisticated tool as
dpkg-shlibdeps.
Anyway, this is superior to not having these dependencies at all,
or to hardcoding them (we still can manually add e.g. a version
constraint if necessary).
- I look for the soname files in a hardcoded list of dirs (/lib,
/usr/lib, /lib/DEB_HOST_MULTIARCH and
/usr/lib/DEB_HOST_MULTIARCH).
dpkg-shlibdeps would be more flexible here, but we just need it
to work for us. Are there any problems with that, e.g. for other
ports (kfreebsd, hurd) or anything else?
For reference, this is my implementation:
d/rules:
# additional dlopen runtime dependencies
sonames=$(shell grep "^\#define SONAME_" include/config.h | cut -d\" -f2)
paths=/usr /usr/lib /lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
/usr/lib/$(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
dlopenRecommends=$(shell \
for soname in $(sonames); do \
for path in $(paths); do \
file=$$(echo $$path/$$soname | sed "s|//|/|g"); \
[ -f $$file ] && dpkg -S $$file | cut -d: -f1 | sed "s/\\(.*\\)
*/\\1,/" && break || true; \
done; \
done)
override_dh_gencontrol:
dh_gencontrol -- \
-Vdlopen:Recommends="$(dlopenRecommends)"
d/control:
libwine Recommends: ${dlopen:Recommends},
Thanks again for the valuable input!
Greets
jre
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
* Jens Reyer , 2016-05-19, 16:57: First off, I'm not sure about every single dependency if it is needed at all. Quick grep over the *.dll.so indeed shows that they use a bunch of libraries you mentioned: $ strings /usr/lib/i386-linux-gnu/wine/*.dll.so | grep '^lib.*[.]so[.]' | sort -u | grep -v '!' libGLU.so.1 libOSMesa.so.8 libOpenCL.so.1 libX11.so.6 libXext.so.6 libc.so.6 libfontconfig.so.1 libfreetype.so.6 libgnutls.so.30 libjpeg.so.62 liblber-2.4.so.2 liblcms2.so.2 libldap_r-2.4.so.2 libm.so.6 libncurses.so.5 libodbc.so.2 libopenal.so.1 libpcap.so.0.8 libpng16.so.16 libpthread.so.0 libresolv.so.2 libtiff.so.5 libwine.so.1 libxml2.so.2 libxslt.so.1 libz.so.1 I guess a better method of obtaining the list of used shared libraries is to grep for "SONAME_" in include/config.h (after it was created by the configure script). Once you have the list of needed shlibs, the simplest way to compute package dependency is to create an ELF that depends on all of them, and then use dpkg-shlibdeps against it. You can steal the idea of how to create such ELF here: https://bitbucket.org/jwilk/python-dctypes/src/default/dctypes2elf -- Jakub Wilk
Re: Adding runtime dependencies that aren't caught by shlibs:Depends
Hi Jens, >Now, assuming that we really need all of them, but that there is no way >to automatically add them: is there any way to compute the needed >runtime dependency for a given builddep, in order to avoid hardcoding >this list and update it with every soname change of a depended upon >package? unfortunately I think there isn't a way. BTW if you do dlopen of a library, there is no guarantee that the latest release will work, so even if such a way would exist, it won't be the safe thing to do. shlibs:Depends guarantees that the correct library is picked up at runtime, and if you want to dlopen it I guess the only way is to manually runtime-depend on the library itself. (we had the same libpng related discussion before on #820566 I think) Gianfranco
Adding runtime dependencies that aren't caught by shlibs:Depends
Hi,
I'm working on adding more runtime dependencies to wine (see #823991).
Wine uses the dh sequencer and all relevant binary packages have a
"Depends: ${shlibs:Depends}". This adds some runtime dependencies, but
by far not for every build-dependency -dev package.
If I try to do that manually I come up with the following list of
builddeps and assumed runtime dependencies:
libxi-dev, libxi6
libxt-dev, libxt6
libxmu-dev, libxmu6
libxrandr-dev, libxrandr2
libxrender-dev, libxrender1
libxkbfile-dev, libxkbfile1
libxxf86vm-dev, libxxf86vm1
libxxf86dga-dev,libxxf86dga1
libxinerama-dev,libxinerama1
libxcomposite-dev, libxcomposite1
libpng-dev, libpng16-16
libssl-dev, libssl1.0.2
libgsm1-dev,libgsm1
libjpeg-dev,libjpeg62-turbo
libtiff-dev,libtiff5
libxslt1-dev, libxslt1.1
unixodbc-dev, libodbc1
libcups2-dev, libcups2
libdbus-1-dev, libdbus-1-3
freeglut3-dev, freeglut3
libosmesa6-dev, libosmesa6
libgnutls28-dev,libgnutls30
libgettextpo-dev, libgettextpo0
First off, I'm not sure about every single dependency if it is needed at
all. Is it reasonable to depend on (or recommend) all these packages,
given that the builddeps were added for a good reason? Or am I on the
completely wrong track here?
So far we only added dependencies manually for:
libncurses5-dev,libncurses5
libfreetype6-dev, libfreetype6
libfontconfig1-dev, libfontconfig1
But I'd assume we just didn't get bugreports for most of the others,
because Wine is such a big beast and many dependencies are just used
seldom and/or installed anyway.
Now, assuming that we really need all of them, but that there is no way
to automatically add them: is there any way to compute the needed
runtime dependency for a given builddep, in order to avoid hardcoding
this list and update it with every soname change of a depended upon
package?
We do so for libncurses5-dev and libfreetype6-dev by stripping the
"-dev" from the builddep line that contains "ncurses" or "freetype". But
this approach unfortunately doesn't work for all packages' naming schemes.
Greets
jre
Re: iipimage-server: unknown substitution variable ${shlibs:Depends}
On Fri, Sep 12, 2014 at 12:13:06PM +0200, Mathieu Malaterre wrote:
> hi,
>
> for some reason, if I recompile iipimage from a sid chroot I keep
> getting a warning:
>
> [...]
> dpkg-gencontrol: warning: Depends field of package iipimage-server:
> unknown substitution variable ${shlibs:Depends}
> [...]
>
> It did worked well in the past. Now even libc is not part of the
> Depends fields. Does anyone see anything wrong in the iipimage package
> ? Thanks.
ifneq (,$(KDU_ROOT))
override_dh_shlibdeps:
endif
Your schroot is broken.
> Steps:
>
> $ schroot -c sid
> $ apt-get source iipimage
> $ cd iipimage-0.9.9
> $ dpkg-buildpackage -rfakeroot -us -uc
> [...]
Unable to reproduce.
P.S. -rfakeroot is default since 2007.
--
WBR, wRAR
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20140912102425.ga17...@belkar.wrar.name
Re: iipimage-server: unknown substitution variable ${shlibs:Depends}
On 09/12/2014 12:13, Mathieu Malaterre wrote:
> for some reason, if I recompile iipimage from a sid chroot I keep
> getting a warning:
>
> [...]
> dpkg-gencontrol: warning: Depends field of package iipimage-server:
> unknown substitution variable ${shlibs:Depends}
> [...]
>
> It did worked well in the past. Now even libc is not part of the
> Depends fields. Does anyone see anything wrong in the iipimage package
> ? Thanks.
Did you set the KDU_ROOT environment variable?
Ansgar
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5412c82a.7000...@43-1.org
iipimage-server: unknown substitution variable ${shlibs:Depends}
hi,
for some reason, if I recompile iipimage from a sid chroot I keep
getting a warning:
[...]
dpkg-gencontrol: warning: Depends field of package iipimage-server:
unknown substitution variable ${shlibs:Depends}
[...]
It did worked well in the past. Now even libc is not part of the
Depends fields. Does anyone see anything wrong in the iipimage package
? Thanks.
Steps:
$ schroot -c sid
$ apt-get source iipimage
$ cd iipimage-0.9.9
$ dpkg-buildpackage -rfakeroot -us -uc
[...]
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
https://lists.debian.org/ca+7wusxpr2rvb71cqxzgxoqcvq97cqs9gpgxkmx3tbpzbn2...@mail.gmail.com
Re: pbuilder and ${shlibs:Depends}
On Sat, 19 Mar 2011, Panayiotis Karabassis wrote: > So, to summarize: > > If: > a) /usr/bin/foo of package foo needs at RUN-TIME /usr/lib/libbar.so > b) /usr/lib/libbar.so is packaged under package libbar > > then I need to: > c) add package libbar-dev as a BUILD dependency of foo. > > And dh_shlibdeps will do its magic? How does this work exactly? Yes. man dpkg-shlibdeps to understand the details. > d) Does libbar-dev provide a DEBIAN/shlibs file that says that libbar.so > is packaged in package libbar? No, "libbar" provides the shlibs/symbols file but libbar-dev depends on libbar so you get it implicitely. And you also need the /usr/include files in libbar-dev... > Is the above correct? Almost. Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110319080436.gb31...@rivendell.home.ouaza.com
Re: pbuilder and ${shlibs:Depends}
On Fri, 18 Mar 2011, Paul Gevers wrote:
> > Unfortunately this is wrong, at least for ELF binaries. Usually if you
> > don't have all the dependencies that you expect, it's because they are
> > optional and are disabled when they are not found during ./configure.
>
> Although I am just a simple DM, I still don't agree completely. Both my
> upstreams call binaries (not libraries) in their programs (via a shell
> or system call). As far as I can tell, that won't (and should not by the
> name) be picked up by the ${shlibs:Depends} variable. Especially for the
> shell call, I don't see an other way than providing it manually.
You're right on this one. But I think the question was about libraries
from the start.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110319080222.ga31...@rivendell.home.ouaza.com
Re: pbuilder and ${shlibs:Depends}
> Unfortunately this is wrong, at least for ELF binaries. Usually if you > don't have all the dependencies that you expect, it's because they are > optional and are disabled when they are not found during ./configure. > > Thus the correct solution is to add the required -dev packages in the > Build-Depends so that ./configure finds the optional libraries that you > want your program to use. So, to summarize: If: a) /usr/bin/foo of package foo needs at RUN-TIME /usr/lib/libbar.so b) /usr/lib/libbar.so is packaged under package libbar then I need to: c) add package libbar-dev as a BUILD dependency of foo. And dh_shlibdeps will do its magic? How does this work exactly? d) Does libbar-dev provide a DEBIAN/shlibs file that says that libbar.so is packaged in package libbar? Is the above correct? > You did not save some complication you just got wrong information due to > this. It's unlikely that jh_depends works like dpkg-shlibdeps. > > I guess you need to have all the jars installed at build time and thus you > want to add them to Build-Depends. But you should really ask for > confirmation someone on debian-java@ or an experienced java packager (or > maybe it's in jh_depends documentation). Indeed. I will post to the appropriate list. Regards, Panayiotis -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d83e270.7080...@gmail.com
Re: pbuilder and ${shlibs:Depends}
>>> Add the missing dependencies manually AND use the variable. (At least
>>> this is what I do in all my packages.
>>
>> Thank you very much! This is really all I needed to know.
>
> Unfortunately this is wrong, at least for ELF binaries. Usually if you
> don't have all the dependencies that you expect, it's because they are
> optional and are disabled when they are not found during ./configure.
Although I am just a simple DM, I still don't agree completely. Both my
upstreams call binaries (not libraries) in their programs (via a shell
or system call). As far as I can tell, that won't (and should not by the
name) be picked up by the ${shlibs:Depends} variable. Especially for the
shell call, I don't see an other way than providing it manually.
> Adding manual dependencies on C libraries is almost always wrong.
Here I think I agree.
Paul
signature.asc
Description: OpenPGP digital signature
Re: pbuilder and ${shlibs:Depends}
On Fri, 18 Mar 2011, Panayiotis Karabassis wrote: > I am still a little confused about this. Could you provide an > example/documentation to clarify this? From experience, I believe that > it WILL expand to LIBRARIES (not executables) that the program needs to > run, if said libraries are installed at build time. If not, what's its > purpose? It will expand to libraries which are listed in the NEEDED section of the ELF binaries present in your package. > > Add the missing dependencies manually AND use the variable. (At least > > this is what I do in all my packages. > > Thank you very much! This is really all I needed to know. Unfortunately this is wrong, at least for ELF binaries. Usually if you don't have all the dependencies that you expect, it's because they are optional and are disabled when they are not found during ./configure. Thus the correct solution is to add the required -dev packages in the Build-Depends so that ./configure finds the optional libraries that you want your program to use. Adding manual dependencies on C libraries is almost always wrong. > BTW, I'm not actually using dpkg-shlibdeps, but rather jh_depends. I > wanted to save some complication, since most developers are probably > more familiar with the former. You did not save some complication you just got wrong information due to this. It's unlikely that jh_depends works like dpkg-shlibdeps. I guess you need to have all the jars installed at build time and thus you want to add them to Build-Depends. But you should really ask for confirmation someone on debian-java@ or an experienced java packager (or maybe it's in jh_depends documentation). Cheers, -- Raphaël Hertzog ◈ Debian Developer Follow my Debian News ▶ http://RaphaelHertzog.com (English) ▶ http://RaphaelHertzog.fr (Français) -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110318194013.ga27...@rivendell.home.ouaza.com
Re: pbuilder and ${shlibs:Depends}
On Fri, Mar 18, 2011 at 04:46:00PM +0200, Panayiotis Karabassis wrote:
> Hi, I have a question regarding pbuilder.
>
> My Debian package uses ${shlibs:Depends} in its Depends field.
>
> However, in a pbuilder environment not all dependencies are installed,
> and hence ${shlibs:Depends} does not expand to *all* real dependencies.
*Build* dependancies are not automatically guessed, you need to provide
explicit Build-Depends so that pbuilder installs them.
{shlibs:Depends} is to be used to produce dependancies for binary packages.
> My question is: how do I add the missing dependencies?
>
> a) Put them in Build-Depends so dpkg-shlibdeps can find them? (ugly)
> b) Drop ${shlibs:Depends} and list them manually?
> c) Something else?
Read:
http://www.debian.org/doc/debian-policy/ap-pkg-sourcepkg.html
http://www.debian.org/doc/debian-policy/ch-sharedlibs.html
--
Simon Paillard
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110318193208.gh12...@glenfiddich.ikibiki.org
Re: pbuilder and ${shlibs:Depends}
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/18/2011 05:57 PM, Paul Gevers wrote: > I believe that this variable will only resolve libraries which you > depend on (and you need the -dev package in the build dependencies). It > will never find a executable which you need to RUN your program. I am still a little confused about this. Could you provide an example/documentation to clarify this? From experience, I believe that it WILL expand to LIBRARIES (not executables) that the program needs to run, if said libraries are installed at build time. If not, what's its purpose? To support the above: >dh_shlibdeps is a debhelper program that is responsible for calculating >shared library dependencies for packages. > >This program is merely a wrapper around dpkg-shlibdeps(1) that calls it >once for each package listed in the control file, passing it a list of >ELF executables and shared libraries it has found. Sorry, I didn't understand the part about the -dev package. I'm a little stupid... :-D > Add the missing dependencies manually AND use the variable. (At least > this is what I do in all my packages. Thank you very much! This is really all I needed to know. BTW, I'm not actually using dpkg-shlibdeps, but rather jh_depends. I wanted to save some complication, since most developers are probably more familiar with the former. > Paul Again thank you, regards, Panayiotis -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNg4tPAAoJEN7RcJcJCZJi0ZYIALLZiRx9plW6aXR0Ef+UzE8O 3JnU35r0OC2IRLSIGleFYN7rVzswcdSxLNjy8NIEVoknrNAYnW014Pyd8JYHyacY ybITtC4vF9V7NYneXty50zRCnF4n9zRdK744rwiQNfDUWdTXbLhv3DQrsuTCwbVW ZwmFZFnFbNO14NbKf+o9YEJKPJa00ZRS92asNDfKmOZS4oqpQdr+rYSQQmrYYXzY lUmOoLz940QyzWseXUScWHdwaxy1wHK+jOHXaF+vdpxEgJ/u/3FVu+MEPdRfjHY3 MpJNCKXPjQ0ULX57zGiHFB4qDUmeQClngxFR9NcpO9pWFsyu4ANFlrkIg8ivzt8= =z29R -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d838b53.6010...@gmail.com
Re: pbuilder and ${shlibs:Depends}
> My Debian package uses ${shlibs:Depends} in its Depends field.
>
> However, in a pbuilder environment not all dependencies are installed,
> and hence ${shlibs:Depends} does not expand to *all* real dependencies.
I believe that this variable will only resolve libraries which you
depend on (and you need the -dev package in the build dependencies). It
will never find a executable which you need to RUN your program.
> My question is: how do I add the missing dependencies?
>
> a) Put them in Build-Depends so dpkg-shlibdeps can find them? (ugly)
I believe this WON't help
> b) Drop ${shlibs:Depends} and list them manually?
> c) Something else?
Add the missing dependencies manually AND use the variable. (At least
this is what I do in all my packages.
Paul
signature.asc
Description: OpenPGP digital signature
pbuilder and ${shlibs:Depends}
Reposted from debian-user:
Hi, I have a question regarding pbuilder.
My Debian package uses ${shlibs:Depends} in its Depends field.
However, in a pbuilder environment not all dependencies are installed,
and hence ${shlibs:Depends} does not expand to *all* real dependencies.
My question is: how do I add the missing dependencies?
a) Put them in Build-Depends so dpkg-shlibdeps can find them? (ugly)
b) Drop ${shlibs:Depends} and list them manually?
c) Something else?
What is the recommended way?
Thanks and regards,
Panayiotis
--
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4d837028.5030...@gmail.com
Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
Rene Engelhard wrote: > Bob Proulx wrote: > > Why does building a package with pbuilder generate the seemingly wrong > > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the > > installed library? What am I doing wrong? > > Nothing. > > [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat > /var/lib/dpkg/info/libc6.shlibs > libc 6 libc6 (>= 2.2.4-4) Thanks for taking the time to answer. I am not unappreciative but unfortunately I did not find this very informative to me. Even that reference to the libc6.shlibs file, while correct, was obtuse to me. So before the mailling list archive gets split into the new month I decided I would get another in with an update with an expansion of this topic. Digging through the dpkg-shlibdeps perl script and I can see where it is reading the file you referenced. Therefore it appears that shared library packages can specify an ABI version separate from their installed package version. The glibc package specifies 2.2.4-4 as the ABI so that even though version 2.2.5-11.5 is installed. The installed value is overridden with the libc6 package specified version from the shlibs file. Digging into the glibc package I see that they manually set the ABI version to 2.2.4-4 in the debian/rules.d/shlibs.mk file. Now knowing a little more about what to look for I was able to locate documentation on the process. Here is the pointer. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Thanks again, Bob pgps4sIwm0slr.pgp Description: PGP signature
Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
Rene Engelhard wrote: > Bob Proulx wrote: > > Why does building a package with pbuilder generate the seemingly wrong > > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the > > installed library? What am I doing wrong? > > Nothing. > > [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat /var/lib/dpkg/info/libc6.shlibs > libc 6 libc6 (>= 2.2.4-4) Thanks for taking the time to answer. I am not unappreciative but unfortunately I did not find this very informative to me. Even that reference to the libc6.shlibs file, while correct, was obtuse to me. So before the mailling list archive gets split into the new month I decided I would get another in with an update with an expansion of this topic. Digging through the dpkg-shlibdeps perl script and I can see where it is reading the file you referenced. Therefore it appears that shared library packages can specify an ABI version separate from their installed package version. The glibc package specifies 2.2.4-4 as the ABI so that even though version 2.2.5-11.5 is installed. The installed value is overridden with the libc6 package specified version from the shlibs file. Digging into the glibc package I see that they manually set the ABI version to 2.2.4-4 in the debian/rules.d/shlibs.mk file. Now knowing a little more about what to look for I was able to locate documentation on the process. Here is the pointer. http://www.debian.org/doc/debian-policy/ch-sharedlibs.html#s-sharedlibs-shlibdeps Thanks again, Bob pgp0.pgp Description: PGP signature
Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
Hi, Bob Proulx wrote: > dpkg-deb --info /var/cache/pbuilder/result/*.deb |grep Depends: >Depends: libc6 (>= 2.2.4-4) > > So then in an attempt to resolve this I add DISTRIBUTION=woody to my Why? This libc6 Depends: is fully correct for builds on woody... > Why does building a package with pbuilder generate the seemingly wrong > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the > installed library? What am I doing wrong? Nothing. [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat /var/lib/dpkg/info/libc6.shlibs libm 6 libc6 (>= 2.2.4-4) libc 6 libc6 (>= 2.2.4-4) /lib/ld-linux 2 libc6 (>= 2.2.4-4) ld-linux 2 libc6 (>= 2.2.4-4) libdl 2 libc6 (>= 2.2.4-4) libutil 1 libc6 (>= 2.2.4-4) libresolv 2 libc6 (>= 2.2.4-4) libnss_files 2 libc6 (>= 2.2.4-4) libnss_dns 2 libc6 (>= 2.2.4-4) libnss_compat 2 libc6 (>= 2.2.4-4) libnss_nis 2 libc6 (>= 2.2.4-4) libnss_nisplus 2 libc6 (>= 2.2.4-4) libnss_ldap 2 libc6 (>= 2.2.4-4) libnss_hesiod 2 libc6 (>= 2.2.4-4) libnsl 1 libc6 (>= 2.2.4-4) libdb 2 libcrypt 1 libc6 (>= 2.2.4-4) libBrokenLocale 1 libc6 (>= 2.2.4-4) librt 1 libc6 (>= 2.2.4-4) libanl 1 libc6 (>= 2.2.4-4) libpthread 0 libc6 (>= 2.2.4-4) libthread_db 1 libc6 (>= 2.2.4-4) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
sudo apt-get install pbuilder
echo 'MIRRORSITE=' > ~/.pbuilderrc # MIRRORSITE= my apt-proxy cache
sudo pbuilder create
cd # some package directory which uses ${shlibs:Depends} in control
grep ^Depends: debian/control
Depends: ${shlibs:Depends}
pdebuild
dpkg-deb --info /var/cache/pbuilder/result/*.deb |grep Depends:
Depends: libc6 (>= 2.2.4-4)
So then in an attempt to resolve this I add DISTRIBUTION=woody to my
$HOME/.pbuilderrc file but I receive the same result. Why doesn't the
depends show up as 2.2.5-11.5? So I login to the chroot area to check.
sudo pbuilder login
dpkg --status libc6 |grep ^Version:
Version: 2.2.5-11.5
Really and truly 2.2.5 is installed in the changeroot. But 2.2.4 is
getting listed as the Depends: for the package getting built. I
manually built a package in the pbuilder chroot with the same result.
So the problem would seem to me to be in dpkg-shlibdeps in the chroot.
No debian/shlibs.local exists. The /etc/dpkg/shlibs.default only
contains comments.
My system is mainly woody but does have a variety of backports.
Thinking this might be something related to the version of pbuilder or
debootstrap I updated to the latest pbuilder from unstable (version
0.96) which required a newer debootstrap which I pulled (version
0.2.9.backports.org.1) but with the same result. And that is when I
decided that someone must have debugged this already and that I would
ask for help.
Why does building a package with pbuilder generate the seemingly wrong
version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
installed library? What am I doing wrong?
Thanks
Bob
pgp2DyYGeGfsL.pgp
Description: PGP signature
Re: pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
Hi, Bob Proulx wrote: > dpkg-deb --info /var/cache/pbuilder/result/*.deb |grep Depends: >Depends: libc6 (>= 2.2.4-4) > > So then in an attempt to resolve this I add DISTRIBUTION=woody to my Why? This libc6 Depends: is fully correct for builds on woody... > Why does building a package with pbuilder generate the seemingly wrong > version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the > installed library? What am I doing wrong? Nothing. [EMAIL PROTECTED]:~$ sudo chroot chroots/stable cat /var/lib/dpkg/info/libc6.shlibs libm 6 libc6 (>= 2.2.4-4) libc 6 libc6 (>= 2.2.4-4) /lib/ld-linux 2 libc6 (>= 2.2.4-4) ld-linux 2 libc6 (>= 2.2.4-4) libdl 2 libc6 (>= 2.2.4-4) libutil 1 libc6 (>= 2.2.4-4) libresolv 2 libc6 (>= 2.2.4-4) libnss_files 2 libc6 (>= 2.2.4-4) libnss_dns 2 libc6 (>= 2.2.4-4) libnss_compat 2 libc6 (>= 2.2.4-4) libnss_nis 2 libc6 (>= 2.2.4-4) libnss_nisplus 2 libc6 (>= 2.2.4-4) libnss_ldap 2 libc6 (>= 2.2.4-4) libnss_hesiod 2 libc6 (>= 2.2.4-4) libnsl 1 libc6 (>= 2.2.4-4) libdb 2 libcrypt 1 libc6 (>= 2.2.4-4) libBrokenLocale 1 libc6 (>= 2.2.4-4) librt 1 libc6 (>= 2.2.4-4) libanl 1 libc6 (>= 2.2.4-4) libpthread 0 libc6 (>= 2.2.4-4) libthread_db 1 libc6 (>= 2.2.4-4) Grüße/Regards, René -- .''`. René Engelhard -- Debian GNU/Linux Developer : :' : http://www.debian.org | http://people.debian.org/~rene/ `. `' [EMAIL PROTECTED] | GnuPG-Key ID: 248AEB73 `- Fingerprint: 41FA F208 28D4 7CA5 19BB 7AD9 F859 90B0 248A EB73 signature.asc Description: Digital signature
pbuilder ${shlibs:Depends} yields libc6-2.2.4-4 ???
I just recently started using pbuilder. Previously I have been
maintaining my own chroots as required. I can see why people
recommend pbuilder. It is very nice! But things do not seem to be
operating as I believe they should and I have been unable to figure
this out. Let me set the stage.
sudo apt-get install pbuilder
echo 'MIRRORSITE=' > ~/.pbuilderrc # MIRRORSITE= my apt-proxy cache
sudo pbuilder create
cd # some package directory which uses ${shlibs:Depends} in control
grep ^Depends: debian/control
Depends: ${shlibs:Depends}
pdebuild
dpkg-deb --info /var/cache/pbuilder/result/*.deb |grep Depends:
Depends: libc6 (>= 2.2.4-4)
So then in an attempt to resolve this I add DISTRIBUTION=woody to my
$HOME/.pbuilderrc file but I receive the same result. Why doesn't the
depends show up as 2.2.5-11.5? So I login to the chroot area to check.
sudo pbuilder login
dpkg --status libc6 |grep ^Version:
Version: 2.2.5-11.5
Really and truly 2.2.5 is installed in the changeroot. But 2.2.4 is
getting listed as the Depends: for the package getting built. I
manually built a package in the pbuilder chroot with the same result.
So the problem would seem to me to be in dpkg-shlibdeps in the chroot.
No debian/shlibs.local exists. The /etc/dpkg/shlibs.default only
contains comments.
My system is mainly woody but does have a variety of backports.
Thinking this might be something related to the version of pbuilder or
debootstrap I updated to the latest pbuilder from unstable (version
0.96) which required a newer debootstrap which I pulled (version
0.2.9.backports.org.1) but with the same result. And that is when I
decided that someone must have debugged this already and that I would
ask for help.
Why does building a package with pbuilder generate the seemingly wrong
version for Depends: of 2.2.4-4 regarldless that 2.2.5-11.5 is the
installed library? What am I doing wrong?
Thanks
Bob
pgp0.pgp
Description: PGP signature
Re: Depends: ${shlibs:Depends}
>> >> I am about that it makes the built binary package depending on >> environment in which is is built. But I think this is acceptable for >> alpha versions of software, which are more for developers than for >> normal users, yes? > > It is required for all packages that link against shared libraries, > whether alpha or not. Regardless of what you put in the Depends: line, > the built binary package does depend on the environment in which it is > built, because of the way dynamic linking works. > further, the environment you build a package in should be similar to the environment your users have. If this is not the case use one of the packages which creates a chroot for compiling packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: ${shlibs:Depends}
>> >> I am about that it makes the built binary package depending on >> environment in which is is built. But I think this is acceptable for >> alpha versions of software, which are more for developers than for >> normal users, yes? > > It is required for all packages that link against shared libraries, > whether alpha or not. Regardless of what you put in the Depends: line, > the built binary package does depend on the environment in which it is > built, because of the way dynamic linking works. > further, the environment you build a package in should be similar to the environment your users have. If this is not the case use one of the packages which creates a chroot for compiling packages. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: ${shlibs:Depends}
On Mon, Jun 24, 2002 at 11:03:30AM +0600, Victor Porton wrote:
> In which situations
>
> Depends: ${shlibs:Depends}
>
> is acceptable and in which is not?
>
> I am about that it makes the built binary package depending on
> environment in which is is built. But I think this is acceptable for
> alpha versions of software, which are more for developers than for
> normal users, yes?
It is required for all packages that link against shared libraries,
whether alpha or not. Regardless of what you put in the Depends: line,
the built binary package does depend on the environment in which it is
built, because of the way dynamic linking works.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Depends: ${shlibs:Depends}
In which situations
Depends: ${shlibs:Depends}
is acceptable and in which is not?
I am about that it makes the built binary package depending on environment in
which is is built. But I think this is acceptable for alpha versions of
software, which are more for developers than for normal users, yes?
--
Victor Porton ([EMAIL PROTECTED])
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Depends: ${shlibs:Depends}
On Mon, Jun 24, 2002 at 11:03:30AM +0600, Victor Porton wrote:
> In which situations
>
> Depends: ${shlibs:Depends}
>
> is acceptable and in which is not?
>
> I am about that it makes the built binary package depending on
> environment in which is is built. But I think this is acceptable for
> alpha versions of software, which are more for developers than for
> normal users, yes?
It is required for all packages that link against shared libraries,
whether alpha or not. Regardless of what you put in the Depends: line,
the built binary package does depend on the environment in which it is
built, because of the way dynamic linking works.
--
Colin Watson [[EMAIL PROTECTED]]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Depends: ${shlibs:Depends}
In which situations
Depends: ${shlibs:Depends}
is acceptable and in which is not?
I am about that it makes the built binary package depending on environment in
which is is built. But I think this is acceptable for alpha versions of
software, which are more for developers than for normal users, yes?
--
Victor Porton ([EMAIL PROTECTED])
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 05:10:24PM -0800, Sean 'Shaleh' Perry wrote: > if he compiled with debhelper from potato there is a good chance he would be > lying about his standards version. The standards-version should match the > standards you were compiled against. OK! That's right. I forgot that debhelper may have changed since potato... ;-) Regards, Nicolas PS: please respect the Mail-Followup-To header. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 05:10:24PM -0800, Sean 'Shaleh' Perry wrote: > if he compiled with debhelper from potato there is a good chance he would be > lying about his standards version. The standards-version should match the > standards you were compiled against. OK! That's right. I forgot that debhelper may have changed since potato... ;-) Regards, Nicolas PS: please respect the Mail-Followup-To header. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
> > I have been working on a particular package on my workstation, which runs > > Sid. Now, I was some days away from my office, and had only my laptop > > (Potato). As my package is not too complicated, I decided to modify it to > > be built with Potato successfully - As I guessed, it was fairly easy... > > The first question of this message is if you notice anything wrong. I am > > working with debhelper... The changes I did were: > > > > - In control, I decreased the standards-version from 3.5.2 to 3.0.1 > > My question may be stupid, but is it really useful to decrease the > stardards-version ? I know that potato's lintian issues a warning for > "newer-standards-version", but it sounds rather pointless when > backporting a package from unstable. > > Am I wrong ? You may be right - I just wanted to make sure this worked in Potato. I desisted from doing it this way - I got convinced to stick with Sid/Woody, as this package will never natively go into potato and many changes have entered the Debian Policy since then. Thanks again. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-1118 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
>> >> - In control, I decreased the standards-version from 3.5.2 to 3.0.1 > > My question may be stupid, but is it really useful to decrease the > stardards-version ? I know that potato's lintian issues a warning for > "newer-standards-version", but it sounds rather pointless when > backporting a package from unstable. > > Am I wrong ? > if he compiled with debhelper from potato there is a good chance he would be lying about his standards version. The standards-version should match the standards you were compiled against. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 04:01:49PM -0600, Gunnar Wolf wrote: > Hi, > > I have been working on a particular package on my workstation, which runs > Sid. Now, I was some days away from my office, and had only my laptop > (Potato). As my package is not too complicated, I decided to modify it to > be built with Potato successfully - As I guessed, it was fairly easy... > The first question of this message is if you notice anything wrong. I am > working with debhelper... The changes I did were: > > - In control, I decreased the standards-version from 3.5.2 to 3.0.1 My question may be stupid, but is it really useful to decrease the stardards-version ? I know that potato's lintian issues a warning for "newer-standards-version", but it sounds rather pointless when backporting a package from unstable. Am I wrong ? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
On Mon, Apr 01, 2002 at 04:01:49PM -0600, Gunnar Wolf wrote:
> dpkg-deb: parse error, in file `debian/tutos/DEBIAN/control' near line 7
> package `tutos':
> `Depends' field, missing package name, or garbage where package name expected
> dh_builddeb: command returned error code
> make: *** [binary-indep] Error 1
>
> I have the following information in my Depends:
>
> Depends: ${shlibs:Depends}, apache | apache-ssl | httpd, php4, php4-pgsql |
> php\4-mysql, php4-pgsql | mysql-client, postgresql-client | php4-mysql,
> postgresql-\client | mysql-client
If you're using dpkg-dev 1.9.0 or above in unstable, dpkg-gencontrol
will remove the trailing comma when it substitutes something empty for
${shlibs:Depends}. The dpkg-dev in stable didn't do this.
As you rightly point out, removing ${shlibs:Depends} is a reasonable
fix. It doesn't sound like you have any shared library dependencies to
be substituted there - programs not written in C/C++ generally don't -
so it's also more correct to remove it in your case.
--
Colin Watson [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
> > I have been working on a particular package on my workstation, which runs > > Sid. Now, I was some days away from my office, and had only my laptop > > (Potato). As my package is not too complicated, I decided to modify it to > > be built with Potato successfully - As I guessed, it was fairly easy... > > The first question of this message is if you notice anything wrong. I am > > working with debhelper... The changes I did were: > > > > - In control, I decreased the standards-version from 3.5.2 to 3.0.1 > > My question may be stupid, but is it really useful to decrease the > stardards-version ? I know that potato's lintian issues a warning for > "newer-standards-version", but it sounds rather pointless when > backporting a package from unstable. > > Am I wrong ? You may be right - I just wanted to make sure this worked in Potato. I desisted from doing it this way - I got convinced to stick with Sid/Woody, as this package will never natively go into potato and many changes have entered the Debian Policy since then. Thanks again. -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-1118 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
>> >> - In control, I decreased the standards-version from 3.5.2 to 3.0.1 > > My question may be stupid, but is it really useful to decrease the > stardards-version ? I know that potato's lintian issues a warning for > "newer-standards-version", but it sounds rather pointless when > backporting a package from unstable. > > Am I wrong ? > if he compiled with debhelper from potato there is a good chance he would be lying about his standards version. The standards-version should match the standards you were compiled against. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
Hi! On Mon, Apr 01, 2002 at 04:01:49PM -0600, Gunnar Wolf wrote: > Hi, > > I have been working on a particular package on my workstation, which runs > Sid. Now, I was some days away from my office, and had only my laptop > (Potato). As my package is not too complicated, I decided to modify it to > be built with Potato successfully - As I guessed, it was fairly easy... > The first question of this message is if you notice anything wrong. I am > working with debhelper... The changes I did were: > > - In control, I decreased the standards-version from 3.5.2 to 3.0.1 My question may be stupid, but is it really useful to decrease the stardards-version ? I know that potato's lintian issues a warning for "newer-standards-version", but it sounds rather pointless when backporting a package from unstable. Am I wrong ? Regards, Nicolas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
>
> I thought the main problem was this strange combination - I removed it to
> no avail, and fiddled with the line until I got the problem: I removed the
> first dependency (${shlibs:Depends}), and it worked correctly.
>
> I have always seen this thing in the dependencies, and I still don't know
> what it means. Can anybody share some light on it?
>
${shlibs} is replaced by the output of dpkg-shlibdeps. debhelper should make a
call to this or you should. This is how the depends on things like libc and
what not get in the control file.
Basically, it runs ldd on your item and then tries to figure out what package
and version each item in the list came from and lists it in the depends.
My package blackbox says:
Depends: ${shlibs:Depends}
and the output is:
Depends: libc6 (>= 2.2.4-4), libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810),
xlibs (>> 4.1.0)
dh_shlibdeps is run in my rules file.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
${shlibs:Depends} - What is it?
Hi,
I have been working on a particular package on my workstation, which runs
Sid. Now, I was some days away from my office, and had only my laptop
(Potato). As my package is not too complicated, I decided to modify it to
be built with Potato successfully - As I guessed, it was fairly easy...
The first question of this message is if you notice anything wrong. I am
working with debhelper... The changes I did were:
- In control, I decreased the standards-version from 3.5.2 to 3.0.1
- In rules, I decreased DH_COMPAT from 3 to 2
That was it.
Now, I had a problem: When building on my Potato machine, I kept running
into this message:
dpkg-deb: parse error, in file `debian/tutos/DEBIAN/control' near line 7
package `tutos':
`Depends' field, missing package name, or garbage where package name expected
dh_builddeb: command returned error code
make: *** [binary-indep] Error 1
I have the following information in my Depends:
Depends: ${shlibs:Depends}, apache | apache-ssl | httpd, php4, php4-pgsql |
php\4-mysql, php4-pgsql | mysql-client, postgresql-client | php4-mysql,
postgresql-\client | mysql-client
(remember my question a couple of days ago regarding some strange
dependencies? Well, here they are :) )
I thought the main problem was this strange combination - I removed it to
no avail, and fiddled with the line until I got the problem: I removed the
first dependency (${shlibs:Depends}), and it worked correctly.
I have always seen this thing in the dependencies, and I still don't know
what it means. Can anybody share some light on it?
Thank you very much.
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-1118
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
On Mon, Apr 01, 2002 at 04:01:49PM -0600, Gunnar Wolf wrote:
> dpkg-deb: parse error, in file `debian/tutos/DEBIAN/control' near line 7 package
>`tutos':
> `Depends' field, missing package name, or garbage where package name expected
> dh_builddeb: command returned error code
> make: *** [binary-indep] Error 1
>
> I have the following information in my Depends:
>
> Depends: ${shlibs:Depends}, apache | apache-ssl | httpd, php4, php4-pgsql |
>php\4-mysql, php4-pgsql | mysql-client, postgresql-client | php4-mysql,
>postgresql-\client | mysql-client
If you're using dpkg-dev 1.9.0 or above in unstable, dpkg-gencontrol
will remove the trailing comma when it substitutes something empty for
${shlibs:Depends}. The dpkg-dev in stable didn't do this.
As you rightly point out, removing ${shlibs:Depends} is a reasonable
fix. It doesn't sound like you have any shared library dependencies to
be substituted there - programs not written in C/C++ generally don't -
so it's also more correct to remove it in your case.
--
Colin Watson [[EMAIL PROTECTED]]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} - What is it?
>
> I thought the main problem was this strange combination - I removed it to
> no avail, and fiddled with the line until I got the problem: I removed the
> first dependency (${shlibs:Depends}), and it worked correctly.
>
> I have always seen this thing in the dependencies, and I still don't know
> what it means. Can anybody share some light on it?
>
${shlibs} is replaced by the output of dpkg-shlibdeps. debhelper should make a
call to this or you should. This is how the depends on things like libc and
what not get in the control file.
Basically, it runs ldd on your item and then tries to figure out what package
and version each item in the list came from and lists it in the depends.
My package blackbox says:
Depends: ${shlibs:Depends}
and the output is:
Depends: libc6 (>= 2.2.4-4), libstdc++2.10-glibc2.2 (>= 1:2.95.4-0.010810),
xlibs (>> 4.1.0)
dh_shlibdeps is run in my rules file.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
${shlibs:Depends} - What is it?
Hi,
I have been working on a particular package on my workstation, which runs
Sid. Now, I was some days away from my office, and had only my laptop
(Potato). As my package is not too complicated, I decided to modify it to
be built with Potato successfully - As I guessed, it was fairly easy...
The first question of this message is if you notice anything wrong. I am
working with debhelper... The changes I did were:
- In control, I decreased the standards-version from 3.5.2 to 3.0.1
- In rules, I decreased DH_COMPAT from 3 to 2
That was it.
Now, I had a problem: When building on my Potato machine, I kept running
into this message:
dpkg-deb: parse error, in file `debian/tutos/DEBIAN/control' near line 7 package
`tutos':
`Depends' field, missing package name, or garbage where package name expected
dh_builddeb: command returned error code
make: *** [binary-indep] Error 1
I have the following information in my Depends:
Depends: ${shlibs:Depends}, apache | apache-ssl | httpd, php4, php4-pgsql |
php\4-mysql, php4-pgsql | mysql-client, postgresql-client | php4-mysql,
postgresql-\client | mysql-client
(remember my question a couple of days ago regarding some strange
dependencies? Well, here they are :) )
I thought the main problem was this strange combination - I removed it to
no avail, and fiddled with the line until I got the problem: I removed the
first dependency (${shlibs:Depends}), and it worked correctly.
I have always seen this thing in the dependencies, and I still don't know
what it means. Can anybody share some light on it?
Thank you very much.
--
Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)5623-1118
PGP key 1024D/8BB527AF 2001-10-23
Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Mike Markley <[EMAIL PROTECTED]> writes: > On Fri, Nov 16, 2001 at 12:20:40PM +0100, Jan-Hendrik Palic wrote: > > But just .. I have a problem for packaging glibwww and glibwww-ssl. > > glibwww is an addition for glib and can be compliled with libwww on the > > one hand and with libwww-ssl and libssl on the other hand from one > > source. > > > > So I will have four packages, glibwww1, glibwww-dev, glibwww-ssl1 and > > glibwww-ssl-dev from one source. > > > > Can anyone give me an advise to realise that? > > Do the build-dependencies conflict? I don't see a libwww package so I can't > look for myself. libwww0 and libwww-ssl0 conflict; by transitivity their -dev package do, too. I don't see Jan-Hendrik's problem, though. Theoretically, libwww-ssl0 should be binary-compatible with libwww0 -- or else viewml, libxmlrpc-c0, and tetex-bin are potentially broken. If libwww-ssl0 is really a drop-in replacement, why not compile against libwww-dev, and let the users decide whether they want -ssl? -- Robbe signature.ng Description: PGP signature
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Mike Markley <[EMAIL PROTECTED]> writes: > On Fri, Nov 16, 2001 at 12:20:40PM +0100, Jan-Hendrik Palic wrote: > > But just .. I have a problem for packaging glibwww and glibwww-ssl. > > glibwww is an addition for glib and can be compliled with libwww on the > > one hand and with libwww-ssl and libssl on the other hand from one > > source. > > > > So I will have four packages, glibwww1, glibwww-dev, glibwww-ssl1 and > > glibwww-ssl-dev from one source. > > > > Can anyone give me an advise to realise that? > > Do the build-dependencies conflict? I don't see a libwww package so I can't > look for myself. libwww0 and libwww-ssl0 conflict; by transitivity their -dev package do, too. I don't see Jan-Hendrik's problem, though. Theoretically, libwww-ssl0 should be binary-compatible with libwww0 -- or else viewml, libxmlrpc-c0, and tetex-bin are potentially broken. If libwww-ssl0 is really a drop-in replacement, why not compile against libwww-dev, and let the users decide whether they want -ssl? -- Robbe signature.ng Description: PGP signature
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
On Fri, Nov 16, 2001 at 12:20:40PM +0100, Jan-Hendrik Palic wrote: > But just .. I have a problem for packaging glibwww and glibwww-ssl. > glibwww is an addition for glib and can be compliled with libwww on the > one hand and with libwww-ssl and libssl on the other hand from one > source. > > So I will have four packages, glibwww1, glibwww-dev, glibwww-ssl1 and > glibwww-ssl-dev from one source. > > Can anyone give me an advise to realise that? Do the build-dependencies conflict? I don't see a libwww package so I can't look for myself. If all of the build dependencies can be installed at once (i.e. libwww and libwww-ssl do not conflict), then you can simply have multiple build, install, and binary targets. gnapster does something like this to build binary packages with and without gnome support from the same source package. You may want to take a look there. -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 Memory is like an orgasm. It's a lot better if you don't have to fake it. - Seymour Cray on virtual memory
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
On Fri, Nov 16, 2001 at 12:20:40PM +0100, Jan-Hendrik Palic wrote: > But just .. I have a problem for packaging glibwww and glibwww-ssl. > glibwww is an addition for glib and can be compliled with libwww on the > one hand and with libwww-ssl and libssl on the other hand from one > source. > > So I will have four packages, glibwww1, glibwww-dev, glibwww-ssl1 and > glibwww-ssl-dev from one source. > > Can anyone give me an advise to realise that? Do the build-dependencies conflict? I don't see a libwww package so I can't look for myself. If all of the build dependencies can be installed at once (i.e. libwww and libwww-ssl do not conflict), then you can simply have multiple build, install, and binary targets. gnapster does something like this to build binary packages with and without gnome support from the same source package. You may want to take a look there. -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 Memory is like an orgasm. It's a lot better if you don't have to fake it. - Seymour Cray on virtual memory -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Hi ... On Mon, Oct 29, 2001 at 02:37:25PM +0100, Robert Bihlmeyer wrote: >Jan-Hendrik Palic <[EMAIL PROTECTED]> writes: >> subvars: >Depending on the exact conditions, you should have a file named >substvars or one or more .substvars files. Was this a >typo, or is that the source of the problem? yes .. :) thnx ... sorry .. But just .. I have a problem for packaging glibwww and glibwww-ssl. glibwww is an addition for glib and can be compliled with libwww on the one hand and with libwww-ssl and libssl on the other hand from one source. So I will have four packages, glibwww1, glibwww-dev, glibwww-ssl1 and glibwww-ssl-dev from one source. Can anyone give me an advise to realise that? I wanted to have a look to w3c-libwww but this don't compile on my PPC-Sidbox. So ... what will be the right way to do it? Greetings and thnx Jan -- One time, you all will be emulated by linux! Jan- Hendrik Palic Url:"http://www.billgotchy.de"; E-Mail: "[EMAIL PROTECTED]" -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w--- O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++ G+++ e+++ h+ r++ z+ --END GEEK CODE BLOCK-- pgpYXEECGFblr.pgp Description: PGP signature
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Hi ... On Mon, Oct 29, 2001 at 02:37:25PM +0100, Robert Bihlmeyer wrote: >Jan-Hendrik Palic <[EMAIL PROTECTED]> writes: >> subvars: >Depending on the exact conditions, you should have a file named >substvars or one or more .substvars files. Was this a >typo, or is that the source of the problem? yes .. :) thnx ... sorry .. But just .. I have a problem for packaging glibwww and glibwww-ssl. glibwww is an addition for glib and can be compliled with libwww on the one hand and with libwww-ssl and libssl on the other hand from one source. So I will have four packages, glibwww1, glibwww-dev, glibwww-ssl1 and glibwww-ssl-dev from one source. Can anyone give me an advise to realise that? I wanted to have a look to w3c-libwww but this don't compile on my PPC-Sidbox. So ... what will be the right way to do it? Greetings and thnx Jan -- One time, you all will be emulated by linux! Jan- Hendrik Palic Url:"http://www.billgotchy.de"; E-Mail: "[EMAIL PROTECTED]" -BEGIN GEEK CODE BLOCK- Version: 3.12 GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w--- O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++ G+++ e+++ h+ r++ z+ --END GEEK CODE BLOCK-- msg04645/pgp0.pgp Description: PGP signature
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Jan-Hendrik Palic <[EMAIL PROTECTED]> writes: > subvars: Depending on the exact conditions, you should have a file named substvars or one or more .substvars files. Was this a typo, or is that the source of the problem? Maybe try setting DH_VERBOSE=1 ... -- Robbe signature.ng Description: PGP signature
Re: dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Jan-Hendrik Palic <[EMAIL PROTECTED]> writes: > subvars: Depending on the exact conditions, you should have a file named substvars or one or more .substvars files. Was this a typo, or is that the source of the problem? Maybe try setting DH_VERBOSE=1 ... -- Robbe signature.ng
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Hi ...
I try to pack glibwww, the name of the packages are glibwww1 and
glibwww-dev. The shared lib is known as libglibwww.so.1.0.0.
But I have problems with understandment the shlibs-system. I have under
debian the shlibs files with the contents.
shlibs:
libglibwww 0.2 libglibwww1 (>> 0.2-0)
shlibs.local:
libglibwww 0.2 libglibwww1 (>> 0.2-0), libglibwww1 (<< 0.2-99)
subvars:
shlibs:Depends=libc6 (>= 2.2.4-2), libwww0 (>= 5.3.2-2) | libwww-ssl0
(>= 5.3.2-2), zlib1g (>= 1:1.1.3)
But at dpkg-buildpackage I got:
dh_shlibdeps
dpkg-shlibdeps debian/tmp/usr/lib/lib*so*
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
What is going wrong?
I want to pack gnome-common, several skripts to create gnome2 source- trees.
There are no binaries and no libs in this package and I this error
message, too
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
What do I have to do here?
Thanx and regards!
Jan
--
One time, you all will be emulated by linux!
Jan- Hendrik Palic
Url:"http://www.billgotchy.de";
E-Mail: "[EMAIL PROTECTED]"
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w---
O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++
G+++ e+++ h+ r++ z+
--END GEEK CODE BLOCK--
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
Hi ...
I try to pack glibwww, the name of the packages are glibwww1 and
glibwww-dev. The shared lib is known as libglibwww.so.1.0.0.
But I have problems with understandment the shlibs-system. I have under
debian the shlibs files with the contents.
shlibs:
libglibwww 0.2 libglibwww1 (>> 0.2-0)
shlibs.local:
libglibwww 0.2 libglibwww1 (>> 0.2-0), libglibwww1 (<< 0.2-99)
subvars:
shlibs:Depends=libc6 (>= 2.2.4-2), libwww0 (>= 5.3.2-2) | libwww-ssl0
(>= 5.3.2-2), zlib1g (>= 1:1.1.3)
But at dpkg-buildpackage I got:
dh_shlibdeps
dpkg-shlibdeps debian/tmp/usr/lib/lib*so*
dh_gencontrol
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
What is going wrong?
I want to pack gnome-common, several skripts to create gnome2 source- trees.
There are no binaries and no libs in this package and I this error
message, too
dpkg-gencontrol: warning: unknown substitution variable ${shlibs:Depends}
What do I have to do here?
Thanx and regards!
Jan
--
One time, you all will be emulated by linux!
Jan- Hendrik Palic
Url:"http://www.billgotchy.de";
E-Mail: "[EMAIL PROTECTED]"
-BEGIN GEEK CODE BLOCK-
Version: 3.12
GCS d- s: a-- C++ UL++ P+++ L+++ E W++ N+ o+ K- w---
O- M- V- PS++ PE Y+ PGP++ t--- 5- X+++ R-- tv- b++ DI-- D+++
G+++ e+++ h+ r++ z+
--END GEEK CODE BLOCK--
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
OK, thanks for this good piece of advice. On Fri, Apr 13, 2001 at 06:10:22PM -0700, Mike Markley wrote: > On Fri, Apr 13, 2001 at 04:30:15PM -0800, Britton <[EMAIL PROTECTED]> spake > forth: > > > > > It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > > > > > Depends: tcl8.0 | tcl8.1 | tcl8.2 > > > > Or mayby just depend on a version greater than 8.0, as you do with > > debhelper in you build depend. But Mayby tcl breaks backward > > compatability a lot and you thing it would be better without that, sort of > > a judgement call I guess. > > > Couple of problems with this... > 1) tcl8.1 doesn't exist in Debian > 2) tcl breaks backwards compatability a *lot* > 3) because of #2, there are separate packages for 8.0, 8.2, and 8.3; >therefore, a simple Depends: tcl (>= 8.0) will not work. > > All in all, "Depends: tclsh | tcl8.2" should generally work for > straightforward > scripts, as the language doesn't tend to change that much between releases, > just the API for the library and various internals. All of the tcl packages > Provide: tclsh, so that'll work for scripts which don't have any insanity > preventing them from working with all modern TCLs. > > Note that lintian complains about depending only on a virtual package, and > while a quick glance doesn't find language in policy which forbids it, that > is just a quick glance ;). > > > -- > Mike Markley <[EMAIL PROTECTED]> > GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 > > "Logic and practical information do not seem to apply here." > "You admit that?" > "To deny the facts would be illogical, Doctor" > - Spock and McCoy, "A Piece of the Action", stardate unknown > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Eric VAN BUGGENHAUT [EMAIL PROTECTED]
Re: shlibs:Depends
OK, thanks for this good piece of advice. On Fri, Apr 13, 2001 at 06:10:22PM -0700, Mike Markley wrote: > On Fri, Apr 13, 2001 at 04:30:15PM -0800, Britton <[EMAIL PROTECTED]> spake forth: > > > > > It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > > > > > Depends: tcl8.0 | tcl8.1 | tcl8.2 > > > > Or mayby just depend on a version greater than 8.0, as you do with > > debhelper in you build depend. But Mayby tcl breaks backward > > compatability a lot and you thing it would be better without that, sort of > > a judgement call I guess. > > > Couple of problems with this... > 1) tcl8.1 doesn't exist in Debian > 2) tcl breaks backwards compatability a *lot* > 3) because of #2, there are separate packages for 8.0, 8.2, and 8.3; >therefore, a simple Depends: tcl (>= 8.0) will not work. > > All in all, "Depends: tclsh | tcl8.2" should generally work for straightforward > scripts, as the language doesn't tend to change that much between releases, > just the API for the library and various internals. All of the tcl packages > Provide: tclsh, so that'll work for scripts which don't have any insanity > preventing them from working with all modern TCLs. > > Note that lintian complains about depending only on a virtual package, and > while a quick glance doesn't find language in policy which forbids it, that > is just a quick glance ;). > > > -- > Mike Markley <[EMAIL PROTECTED]> > GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 > > "Logic and practical information do not seem to apply here." > "You admit that?" > "To deny the facts would be illogical, Doctor" > - Spock and McCoy, "A Piece of the Action", stardate unknown > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > -- Eric VAN BUGGENHAUT [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
Mike Markley <[EMAIL PROTECTED]> writes: > All in all, "Depends: tclsh | tcl8.2" should generally work [...] > Note that lintian complains about depending only on a virtual package, and > while a quick glance doesn't find language in policy which forbids it, that > is just a quick glance ;). The "real package" alternative is for the sake of the package tools. IOW, the above means: any tclsh will do, but if none is installed, install tcl8.2. For example, "apt install your_package" will automatically add tcl8.2 in this case. dselect will dump you in a screen listing all packages providing tclsh, with tcl8.2. pre-selected as default. (I couldn't find it in policy either, it's just "unwritten law".) -- Robbe signature.ng Description: PGP signature
Re: shlibs:Depends
Mike Markley <[EMAIL PROTECTED]> writes: > All in all, "Depends: tclsh | tcl8.2" should generally work [...] > Note that lintian complains about depending only on a virtual package, and > while a quick glance doesn't find language in policy which forbids it, that > is just a quick glance ;). The "real package" alternative is for the sake of the package tools. IOW, the above means: any tclsh will do, but if none is installed, install tcl8.2. For example, "apt install your_package" will automatically add tcl8.2 in this case. dselect will dump you in a screen listing all packages providing tclsh, with tcl8.2. pre-selected as default. (I couldn't find it in policy either, it's just "unwritten law".) -- Robbe signature.ng
Re: shlibs:Depends
On Fri, Apr 13, 2001 at 04:30:15PM -0800, Britton <[EMAIL PROTECTED]> spake forth: > > > It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > > > Depends: tcl8.0 | tcl8.1 | tcl8.2 > > Or mayby just depend on a version greater than 8.0, as you do with > debhelper in you build depend. But Mayby tcl breaks backward > compatability a lot and you thing it would be better without that, sort of > a judgement call I guess. Couple of problems with this... 1) tcl8.1 doesn't exist in Debian 2) tcl breaks backwards compatability a *lot* 3) because of #2, there are separate packages for 8.0, 8.2, and 8.3; therefore, a simple Depends: tcl (>= 8.0) will not work. All in all, "Depends: tclsh | tcl8.2" should generally work for straightforward scripts, as the language doesn't tend to change that much between releases, just the API for the library and various internals. All of the tcl packages Provide: tclsh, so that'll work for scripts which don't have any insanity preventing them from working with all modern TCLs. Note that lintian complains about depending only on a virtual package, and while a quick glance doesn't find language in policy which forbids it, that is just a quick glance ;). -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 "Logic and practical information do not seem to apply here." "You admit that?" "To deny the facts would be illogical, Doctor" - Spock and McCoy, "A Piece of the Action", stardate unknown
Re: shlibs:Depends
> It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > Depends: tcl8.0 | tcl8.1 | tcl8.2 Or mayby just depend on a version greater than 8.0, as you do with debhelper in you build depend. But Mayby tcl breaks backward compatability a lot and you thing it would be better without that, sort of a judgement call I guess. Britton
Re: shlibs:Depends
On Fri, Apr 13, 2001 at 12:05:39PM -0500, Gordon Sadler wrote:
> On Thu, Apr 12, 2001 at 03:56:40PM +0200, [EMAIL PROTECTED] wrote:
> > I'm building a package which is a simple tcl script. No binaries. Do I need
> > to
> > Depends: ${shlibs:Depends} ?
> >
> > Or is this fine :
> >
> > [EMAIL PROTECTED]:~/debian/s25manager-0.82]$ less debian/control
> > Source: s25manager
> > Section: main/comm
> > Priority: optional
> > Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]>
> > Build-Depends: debhelper (>> 2.0.0)
> > Standards-Version: 3.2.1
> >
> > Package: s25manager
> > Architecture: all
> > Depends: tcl8.2
> > Description: Siemens S25 cell phone GUI manager
> > s25manager is a GUI manager for the S25 series (S25, M35, M35i, etc)
> > Siemens
> > cell phones. It backs up and restores phonebooks, upload logos and midi
> > files, etc.
> >
> You say it's only a script? As scripts generally speaking, don't use
> shared libraries... You just declare your depends manually.
>
> BTW, are you sure it only works with tcl8.2? not 8.0,8.1,8.3?
>
> Gordon Sadler
>
>
It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about :
Depends: tcl8.0 | tcl8.1 | tcl8.2
?
--
[EMAIL PROTECTED]
http://www.eric.ath.cx
Please don't send proprietary format documents, I can't (and don't want to)
open them.
Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are
welcome.
Re: shlibs:Depends
On Fri, Apr 13, 2001 at 04:30:15PM -0800, Britton <[EMAIL PROTECTED]> spake forth: > > > It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > > > Depends: tcl8.0 | tcl8.1 | tcl8.2 > > Or mayby just depend on a version greater than 8.0, as you do with > debhelper in you build depend. But Mayby tcl breaks backward > compatability a lot and you thing it would be better without that, sort of > a judgement call I guess. Couple of problems with this... 1) tcl8.1 doesn't exist in Debian 2) tcl breaks backwards compatability a *lot* 3) because of #2, there are separate packages for 8.0, 8.2, and 8.3; therefore, a simple Depends: tcl (>= 8.0) will not work. All in all, "Depends: tclsh | tcl8.2" should generally work for straightforward scripts, as the language doesn't tend to change that much between releases, just the API for the library and various internals. All of the tcl packages Provide: tclsh, so that'll work for scripts which don't have any insanity preventing them from working with all modern TCLs. Note that lintian complains about depending only on a virtual package, and while a quick glance doesn't find language in policy which forbids it, that is just a quick glance ;). -- Mike Markley <[EMAIL PROTECTED]> GPG: 0x3B047084 7FC7 0DC0 EF31 DF83 7313 FE2B 77A8 F36A 3B04 7084 "Logic and practical information do not seem to apply here." "You admit that?" "To deny the facts would be illogical, Doctor" - Spock and McCoy, "A Piece of the Action", stardate unknown -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
> It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about : > > Depends: tcl8.0 | tcl8.1 | tcl8.2 Or mayby just depend on a version greater than 8.0, as you do with debhelper in you build depend. But Mayby tcl breaks backward compatability a lot and you thing it would be better without that, sort of a judgement call I guess. Britton -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
On Fri, Apr 13, 2001 at 12:05:39PM -0500, Gordon Sadler wrote:
> On Thu, Apr 12, 2001 at 03:56:40PM +0200, [EMAIL PROTECTED] wrote:
> > I'm building a package which is a simple tcl script. No binaries. Do I need to
> > Depends: ${shlibs:Depends} ?
> >
> > Or is this fine :
> >
> > [eric@femto:~/debian/s25manager-0.82]$ less debian/control
> > Source: s25manager
> > Section: main/comm
> > Priority: optional
> > Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]>
> > Build-Depends: debhelper (>> 2.0.0)
> > Standards-Version: 3.2.1
> >
> > Package: s25manager
> > Architecture: all
> > Depends: tcl8.2
> > Description: Siemens S25 cell phone GUI manager
> > s25manager is a GUI manager for the S25 series (S25, M35, M35i, etc) Siemens
> > cell phones. It backs up and restores phonebooks, upload logos and midi files,
>etc.
> >
> You say it's only a script? As scripts generally speaking, don't use
> shared libraries... You just declare your depends manually.
>
> BTW, are you sure it only works with tcl8.2? not 8.0,8.1,8.3?
>
> Gordon Sadler
>
>
It actually works with tcl 8.0, 8.1 and 8.2 you are right. So what about :
Depends: tcl8.0 | tcl8.1 | tcl8.2
?
--
[EMAIL PROTECTED]
http://www.eric.ath.cx
Please don't send proprietary format documents, I can't (and don't want to) open them.
Appreciated are open-source formats like .txt or .rtf. Dvi, ps or tex files are
welcome.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: shlibs:Depends
On Thu, Apr 12, 2001 at 03:56:40PM +0200, [EMAIL PROTECTED] wrote:
> I'm building a package which is a simple tcl script. No binaries. Do I need to
> Depends: ${shlibs:Depends} ?
>
> Or is this fine :
>
> [EMAIL PROTECTED]:~/debian/s25manager-0.82]$ less debian/control
> Source: s25manager
> Section: main/comm
> Priority: optional
> Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>> 2.0.0)
> Standards-Version: 3.2.1
>
> Package: s25manager
> Architecture: all
> Depends: tcl8.2
> Description: Siemens S25 cell phone GUI manager
> s25manager is a GUI manager for the S25 series (S25, M35, M35i, etc) Siemens
> cell phones. It backs up and restores phonebooks, upload logos and midi
> files, etc.
>
You say it's only a script? As scripts generally speaking, don't use
shared libraries... You just declare your depends manually.
BTW, are you sure it only works with tcl8.2? not 8.0,8.1,8.3?
Gordon Sadler
shlibs:Depends
I'm building a package which is a simple tcl script. No binaries. Do I need to
Depends: ${shlibs:Depends} ?
Or is this fine :
[EMAIL PROTECTED]:~/debian/s25manager-0.82]$ less debian/control
Source: s25manager
Section: main/comm
Priority: optional
Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 2.0.0)
Standards-Version: 3.2.1
Package: s25manager
Architecture: all
Depends: tcl8.2
Description: Siemens S25 cell phone GUI manager
s25manager is a GUI manager for the S25 series (S25, M35, M35i, etc) Siemens
cell phones. It backs up and restores phonebooks, upload logos and midi files,
etc.
--
Eric VAN BUGGENHAUT
[EMAIL PROTECTED]
Re: shlibs:Depends
On Thu, Apr 12, 2001 at 03:56:40PM +0200, [EMAIL PROTECTED] wrote:
> I'm building a package which is a simple tcl script. No binaries. Do I need to
> Depends: ${shlibs:Depends} ?
>
> Or is this fine :
>
> [eric@femto:~/debian/s25manager-0.82]$ less debian/control
> Source: s25manager
> Section: main/comm
> Priority: optional
> Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]>
> Build-Depends: debhelper (>> 2.0.0)
> Standards-Version: 3.2.1
>
> Package: s25manager
> Architecture: all
> Depends: tcl8.2
> Description: Siemens S25 cell phone GUI manager
> s25manager is a GUI manager for the S25 series (S25, M35, M35i, etc) Siemens
> cell phones. It backs up and restores phonebooks, upload logos and midi files, etc.
>
You say it's only a script? As scripts generally speaking, don't use
shared libraries... You just declare your depends manually.
BTW, are you sure it only works with tcl8.2? not 8.0,8.1,8.3?
Gordon Sadler
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
shlibs:Depends
I'm building a package which is a simple tcl script. No binaries. Do I need to
Depends: ${shlibs:Depends} ?
Or is this fine :
[eric@femto:~/debian/s25manager-0.82]$ less debian/control
Source: s25manager
Section: main/comm
Priority: optional
Maintainer: Eric Van Buggenhaut <[EMAIL PROTECTED]>
Build-Depends: debhelper (>> 2.0.0)
Standards-Version: 3.2.1
Package: s25manager
Architecture: all
Depends: tcl8.2
Description: Siemens S25 cell phone GUI manager
s25manager is a GUI manager for the S25 series (S25, M35, M35i, etc) Siemens
cell phones. It backs up and restores phonebooks, upload logos and midi files, etc.
--
Eric VAN BUGGENHAUT
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ${shlibs:Depends} problem
First of all, PLEASE turn off HTML in your mails.
On Fri, Mar 09, 2001 at 04:45:52PM -0800, scud wrote:
>when I try to build any debian package the ${shlibs:Depends} statement
>in control file seems not to work. The place in "Depends:" line, where the
>xlib,... should be listed, is free. dh_shlibdepends and dh_gencontrol are
>present in "rules" file.
You should verify that there are binaries actually installed in places where
dh_shlibdeps is looking, debian//usr/bin or so. If that's okay,
then check what ldd/objdump says about them.
> And something else... the "dh_movefiles" line in "rules" is missing "#"
>char every time I run dh_make -l
Er, what? There shouldn't be any hashes needed on that line... see
/usr/share/debhelper/dh_make/debianl/rules for the original template; maybe
there's a bug somewhere.
--
Digital Electronic Being Intended for Assassination and Nullification
Re: ${shlibs:Depends} problem
First of all, PLEASE turn off HTML in your mails.
On Fri, Mar 09, 2001 at 04:45:52PM -0800, scud wrote:
>when I try to build any debian package the ${shlibs:Depends} statement
>in control file seems not to work. The place in "Depends:" line, where the
>xlib,... should be listed, is free. dh_shlibdepends and dh_gencontrol are
>present in "rules" file.
You should verify that there are binaries actually installed in places where
dh_shlibdeps is looking, debian//usr/bin or so. If that's okay,
then check what ldd/objdump says about them.
> And something else... the "dh_movefiles" line in "rules" is missing "#"
>char every time I run dh_make -l
Er, what? There shouldn't be any hashes needed on that line... see
/usr/share/debhelper/dh_make/debianl/rules for the original template; maybe
there's a bug somewhere.
--
Digital Electronic Being Intended for Assassination and Nullification
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
${shlibs:Depends} problem
Hi everybody,
when I try to build any debian package the ${shlibs:Depends} statement
in control file seems not to work. The place in "Depends:" line, where the
xlib,... should be listed, is free. dh_shlibdepends and dh_gencontrol are
present in "rules" file. I'm working with debian potato. Trying to build
glib, gtk+, and other Gnome stuff.
And something else... the "dh_movefiles" line in "rules" is missing "#" char every time I run dh_make -l
If you know how to solve any of these, please help.
Thanks -SCUD
${shlibs:Depends} problem
Hi everybody,
when I try to build any debian package the ${shlibs:Depends} statement
in control file seems not to work. The place in "Depends:" line, where the
xlib,... should be listed, is free. dh_shlibdepends and dh_gencontrol are
present in "rules" file. I'm working with debian potato. Trying to build
glib, gtk+, and other Gnome stuff.
And something else... the "dh_movefiles" line in "rules" is missing "#" char every time I run dh_make -l
If you know how to solve any of these, please help.
Thanks -SCUD
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: control file and {shlibs:Depends}
On Mon, Mar 05, 2001 at 12:32:54PM +0100, Tom Cato Amundsen wrote:
> Is it ok to configure a package differently on one arch?
> I want to build solfege with --disable-oss-sound on m68k until
> the binutils/glibc problems are fixed.
>
> If I use --disable-oss-sound (only on m68k), the package contains
> only python code, so ${shlibs:Depends} is an empty string. And then
> dpkg-deb will complain because the Depends: line ends with a comma (,).
Have a look at the fvwm1 package: in debian/rules I do this (where my
issue was about an empty ${shlibs:Suggests}):
clean:
...
if [ -f debian/control.suggests ]; then \
mv debian/control.suggests debian/control; fi
...
binary-arch:
...
dh_shlibdeps -XFvwmAudio -- \
-dSuggests $(TMP)/usr/X11R6/lib/X11/fvwm/FvwmAudio
# Overwrite the control file if necessary
cd debian && \
if ! grep 'shlibs:Suggests=' substvars >/dev/null 2>&1; \
then cp control control.suggests && \
sed -e 's/, \$${shlibs:Suggests}//' < control.suggests > control; \
fi
dh_gencontrol
...
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
Re: control file and {shlibs:Depends}
On Mon, Mar 05, 2001 at 12:32:54PM +0100, Tom Cato Amundsen wrote:
> Is it ok to configure a package differently on one arch?
> I want to build solfege with --disable-oss-sound on m68k until
> the binutils/glibc problems are fixed.
>
> If I use --disable-oss-sound (only on m68k), the package contains
> only python code, so ${shlibs:Depends} is an empty string. And then
> dpkg-deb will complain because the Depends: line ends with a comma (,).
>
> Is there a way out of this? I can of course bug the ftp admins
You could use a different control file for m68k, or apply a patch for it. We
used to do something similar for xfree for some time, since dpkg or
something else gave back wrong information, and we got this comma problem
when building the libc5 debs.
Check http://buildd.debian.org/andrea/m68k/source-dependencies-stable.gz
and look for *XFREE-LIBC5-PATCH
If you want something like this implemented for your package, you could
write the patch and send it to Roman, to add it to the source-depends for
the buildds. If Roman has to write _and_ implemente it, it might take a
little longer until its in.
Christian
--
http://people.debian.org/~cts/debian-m68k/potato
control file and {shlibs:Depends}
Is it ok to configure a package differently on one arch?
I want to build solfege with --disable-oss-sound on m68k until
the binutils/glibc problems are fixed.
If I use --disable-oss-sound (only on m68k), the package contains
only python code, so ${shlibs:Depends} is an empty string. And then
dpkg-deb will complain because the Depends: line ends with a comma (,).
Is there a way out of this? I can of course bug the ftp admins
to remove the old m68k package from the pool, then the builddeamon
will fail for m68k, and solfege will go into teseting. But I'd like
to have the package for m68k too. The program is still very usable
compiled with --disable-oss-sound, only a little sluggish.
Package: solfege
Architecture: any
Depends: python-gnome (>=1.0.50), python-gtk (>= 0.6.3), python-base (>=1.5.2),
${shlibs:Depends}
Description: Eartraining program for GNOME
--
Tom Cato Amundsen <[EMAIL PROTECTED]>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
Re: control file and {shlibs:Depends}
On Mon, Mar 05, 2001 at 12:32:54PM +0100, Tom Cato Amundsen wrote:
> Is it ok to configure a package differently on one arch?
> I want to build solfege with --disable-oss-sound on m68k until
> the binutils/glibc problems are fixed.
>
> If I use --disable-oss-sound (only on m68k), the package contains
> only python code, so ${shlibs:Depends} is an empty string. And then
> dpkg-deb will complain because the Depends: line ends with a comma (,).
Have a look at the fvwm1 package: in debian/rules I do this (where my
issue was about an empty ${shlibs:Suggests}):
clean:
...
if [ -f debian/control.suggests ]; then \
mv debian/control.suggests debian/control; fi
...
binary-arch:
...
dh_shlibdeps -XFvwmAudio -- \
-dSuggests $(TMP)/usr/X11R6/lib/X11/fvwm/FvwmAudio
# Overwrite the control file if necessary
cd debian && \
if ! grep 'shlibs:Suggests=' substvars >/dev/null 2>&1; \
then cp control control.suggests && \
sed -e 's/, \$${shlibs:Suggests}//' < control.suggests > control; \
fi
dh_gencontrol
...
Julian
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Julian Gilbey, Dept of Maths, Queen Mary, Univ. of London
Debian GNU/Linux Developer, see http://people.debian.org/~jdg
Donate free food to the world's hungry: see http://www.thehungersite.com/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: control file and {shlibs:Depends}
On Mon, Mar 05, 2001 at 12:32:54PM +0100, Tom Cato Amundsen wrote:
> Is it ok to configure a package differently on one arch?
> I want to build solfege with --disable-oss-sound on m68k until
> the binutils/glibc problems are fixed.
>
> If I use --disable-oss-sound (only on m68k), the package contains
> only python code, so ${shlibs:Depends} is an empty string. And then
> dpkg-deb will complain because the Depends: line ends with a comma (,).
>
> Is there a way out of this? I can of course bug the ftp admins
You could use a different control file for m68k, or apply a patch for it. We
used to do something similar for xfree for some time, since dpkg or
something else gave back wrong information, and we got this comma problem
when building the libc5 debs.
Check http://buildd.debian.org/andrea/m68k/source-dependencies-stable.gz
and look for *XFREE-LIBC5-PATCH
If you want something like this implemented for your package, you could
write the patch and send it to Roman, to add it to the source-depends for
the buildds. If Roman has to write _and_ implemente it, it might take a
little longer until its in.
Christian
--
http://people.debian.org/~cts/debian-m68k/potato
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
control file and {shlibs:Depends}
Is it ok to configure a package differently on one arch?
I want to build solfege with --disable-oss-sound on m68k until
the binutils/glibc problems are fixed.
If I use --disable-oss-sound (only on m68k), the package contains
only python code, so ${shlibs:Depends} is an empty string. And then
dpkg-deb will complain because the Depends: line ends with a comma (,).
Is there a way out of this? I can of course bug the ftp admins
to remove the old m68k package from the pool, then the builddeamon
will fail for m68k, and solfege will go into teseting. But I'd like
to have the package for m68k too. The program is still very usable
compiled with --disable-oss-sound, only a little sluggish.
Package: solfege
Architecture: any
Depends: python-gnome (>=1.0.50), python-gtk (>= 0.6.3), python-base (>=1.5.2),
${shlibs:Depends}
Description: Eartraining program for GNOME
--
Tom Cato Amundsen <[EMAIL PROTECTED]>
GNU Solfege - free eartraining, http://www.gnu.org/software/solfege/
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
