|
Home > Archive > Debian Developers > January 2004 > Build-depends method
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Build-depends method
|
|
| Shaun Jackman 2004-01-25, 6:26 am |
| When packaging a new package, what's a methodical way to find *all*
its Build-Depends packages? Currently, I go through the automatically
generated list of Depends packages, and add the corresponding -dev
package. Last my last package though, I missed that the package
depends on flex and yacc. So my rigorous method is, upload package,
wait for FTBFS bug, add Build-Depends, wash, rinse, repeat. I know,
you're allowed to cry now. How should this work?
Please cc me in your reply.
Thanks,
Shaun
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Wouter Verhelst 2004-01-25, 6:33 am |
| On Sun, Jan 25, 2004 at 11:29:07AM -0800, Shaun Jackman wrote:quote:
> When packaging a new package, what's a methodical way to find *all*
> its Build-Depends packages? Currently, I go through the automatically
> generated list of Depends packages, and add the corresponding -dev
> package. Last my last package though, I missed that the package
> depends on flex and yacc. So my rigorous method is, upload package,
> wait for FTBFS bug, add Build-Depends, wash, rinse, repeat. I know,
> you're allowed to cry now. How should this work?
I think you'll find the package "pbuilder" to be exactly what you need.
--
Wouter Verhelst
Debian GNU/Linux -- http://www.debian.org
Nederlandstalige Linux-documentatie -- http://nl.linux.org
"Stop breathing down my neck." "My breathing is merely a simulation."
"So is my neck, stop it anyway!"
-- Voyager's EMH versus the Prometheus' EMH, stardate 51462.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Joerg Jaspert 2004-01-25, 6:33 am |
| | |
| Martin Pitt 2004-01-25, 7:38 am |
| Hi!
On 2004-01-25 11:29 -0800, Shaun Jackman wrote:quote:
> When packaging a new package, what's a methodical way to find *all*
> its Build-Depends packages? Currently, I go through the automatically
> generated list of Depends packages, and add the corresponding -dev
> package. Last my last package though, I missed that the package
> depends on flex and yacc. So my rigorous method is, upload package,
> wait for FTBFS bug, add Build-Depends, wash, rinse, repeat. I know,
> you're allowed to cry now. How should this work?
You really should test whether your build-dependencies are sufficient
by building it within a clean sid pbuilder environment. If that works,
then all required build dependencies are declared (however, there may
be some which are not necessary). IMHO waiting for FTBFS bugs is a
waste of both human resources (these bugs need to be written and dealt
with) and autobuilder time.
I always determine a minimal set of build-deps iteratively like this:
I start only with the "obvious" dependencies, then pdebuild (that is a
script which builds the package in a pbuilder chroot), and look where
the building stops. Mostly it cries for missing header files, then a
'dpkg -S foo.h' gives the package providing it. Repeat until package
builds.
Have a nice day!
Martin
--
Martin Pitt Debian GNU/Linux Developer
martin@piware.de mpitt@debian.org
http://www.piware.de http://www.debian.org
| |
| Henning Makholm 2004-01-25, 7:38 am |
| Scripsit Shaun Jackman <sjackman@telus.net>
quote:
> When packaging a new package, what's a methodical way to find *all*
> its Build-Depends packages?
One fairly effective method is to try to build in a chroot (see
pbuilder etc) with only build-essential packages installed initially.
It's not entirely foolproof because the package may depend on directly
on a-dev and b-dev, but if a-dev currently depends on b-dev you might
miss the explicit build-dependency, which can cause FTBFS's if a-dev
later stops depending on b-dev.
It's also a good idea to check the ldd output from the chroot-built
package against the output from one build in one's usual environment.
If there's a difference, the upstream source's configure script is
probably doing some autodetection of available libraries, and you need
to figure out which ones you want the Debian package to include, and
explicitly tune out the rest with --without-foo arguments to configure.
--
Henning Makholm "Det er jo svært at vide noget når man ikke ved det, ikke?"
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Robert T. Johnson 2004-01-25, 7:38 am |
| On Sun, 2004-01-25 at 11:29, Shaun Jackman wrote:quote:
> When packaging a new package, what's a methodical way to find *all*
> its Build-Depends packages? Currently, I go through the automatically
> generated list of Depends packages, and add the corresponding -dev
> package. Last my last package though, I missed that the package
> depends on flex and yacc. So my rigorous method is, upload package,
> wait for FTBFS bug, add Build-Depends, wash, rinse, repeat. I know,
> you're allowed to cry now. How should this work?
auto-apt uses some LD_PRELOAD hacks to track down build-depends. From
the man page:
auto-apt debuild [debuildopts]
Run debuild(1) in auto-apt environments, and show
Build-Depends: estimation. Recommended to use with
-s option of auto-apt.
I've never used it for this purpose, but I have used it to install
non-packaged software from source, and it's a huge time-saver.
You'll probably still want to run your package through pbuilder, but
auto-apt might save you a few iterations and a lot of hassle.
Best,
Rob
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Steinar H. Gunderson 2004-01-25, 8:34 am |
| On Sun, Jan 25, 2004 at 11:29:07AM -0800, Shaun Jackman wrote:quote:
> When packaging a new package, what's a methodical way to find *all*
> its Build-Depends packages?
I was surprised nobody brought this pearl from the maint-guide up yet:
strace -f -o /tmp/log ./configure
# or make instead of ./configure, if the package doesn't use autoconf
for x in `dpkg -S $(grep open /tmp/log|perl -pe 's!.*open\(\"([^\"]*).*!$1!' |grep "^/"| sort | uniq| grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|cut -f1 -d":"| sort | uniq`; do echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; done
:-)
/* Steinar */
--
Homepage: http://www.sesse.net/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Antti-Juhani Kaijanaho 2004-01-26, 12:34 am |
| On 20040125T112907-0800, Shaun Jackman wrote:quote:
> When packaging a new package, what's a methodical way to find *all*
> its Build-Depends packages?
What I do is I get familiar with the package. I read upstream notes
about required packages, I read through the configure.in or
configure.ac, if any, checking for which libraries and programs are
being looked for, I read Makefiles, I look at each source file,
searching for #includes or imports that do not belong to the standard
packages and so on. And yes, I look at shlibdeps output 
IMHO the "building in a chroot" method suggested by others is not a
substitute for this. For one thing, a missing build-time dependency may
cause the configuration script to disable a feature instead of aborting
the build. Also, if building in a chroot is the only method used,
important information required to make a good Build-Depends line is
missing: you should list packages *you* need, not what your other
build-time depends need, and there is no information helping in choosing an
appropriate versioned build-depends, which is a policy requirement (one
that is often hard to follow even with my method but nearly impossible
without it).
I generally don't build in a chroot, and I rarely get
Build-Depends-related FTBFS bugs; and those that I do get frequently are
of the kind that I would not have caught if I had built in a chroot.
However, building in a chroot never hurts, if you have a setup that
makes it easy.
--
Antti-Juhani Kaijanaho, Debian developer
http://kaijanaho.info/antti-juhani/blog/en/debian
| |
| Lars Wirzenius 2004-01-26, 1:34 am |
| ma, 2004-01-26 kello 15:47, Antti-Juhani Kaijanaho kirjoitti:quote:
> I generally don't build in a chroot, and I rarely get
> Build-Depends-related FTBFS bugs
I generally have also not built in a chroot, and I have had several
FTBFS bugs because of this. Reading upstream READMEs and stuff hasn't
helped me, because I wrote them myself...
It is sometimes suprising how easy it is to figure out the exact build
dependencies. Things in the free software world seem to be growing ever
more complicated and interdependent. chroot can really help here (as
Antti-Juhani said in the part I deleted).
--
http://liw.iki.fi/liw/log/
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Sven Luther 2004-01-26, 2:34 am |
| On Sun, Jan 25, 2004 at 10:13:21PM +0100, Steinar H. Gunderson wrote:quote:
> On Sun, Jan 25, 2004 at 11:29:07AM -0800, Shaun Jackman wrote:
>
> I was surprised nobody brought this pearl from the maint-guide up yet:
>
> strace -f -o /tmp/log ./configure
> # or make instead of ./configure, if the package doesn't use autoconf
> for x in `dpkg -S $(grep open /tmp/log|perl -pe 's!.*open\(\"([^\"]*).*!$1!' |grep "^/"| sort | uniq| grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|cut -f1 -d":"| sort | uniq`; do echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; done
Will this not catch also the programs that are probed but maybe not used
or something ? An example is forexample a packages whose configure
probes for either bison or yacc, but you need only one in the
build-dependencies, or maybe not, since i guess this is build-essential
or something.
Maybe it would be better to check the actual build, not the configure
process, and have some posttreatment which will explore the dependency
tree and find the smallest subset thereof.
Friendly,
Sven Luther
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Florent Rougon 2004-01-26, 3:34 am |
| Sven Luther <sven.luther@wanadoo.fr> wrote:
quote:
> Will this not catch also the programs that are probed but maybe not used
> or something ? An example is forexample a packages whose configure
> probes for either bison or yacc, but you need only one in the
> build-dependencies, or maybe not, since i guess this is build-essential
> or something.
Right, I would never trust the command mentioned by Steinar. Also, he
did put a smiley at the end of his mail, so I guess he didn't mean it
seriously.
quote:
> Maybe it would be better to check the actual build, not the configure
> process, and have some posttreatment which will explore the dependency
> tree and find the smallest subset thereof.
Frankly, I fail to understand the problem people have with:
- thinking before your start filling in the Build-Depends (for tools
that you need to do the build but are not shared libraries and won't
be found by the following methods);
- running "objdump -p" on the binaries included in the generated
binary packages and using "dpkg_-S" to find the corresponding dev
packages (if the Dynamic Section lists libfoo.so.2 as NEEDED,
"dpkg_-S_[/usr/lib/]libfoo.so" will usually find the dev package);
- alternatively, looking in the Depends: fields generated by
dh_shlibdeps and finding the related dev packages with "dpkg -L" and
"dpkg -S" or your favorite apt/dpkg frontend;
- always using your favorite apt/dpkg frontend to make sure your have
considered all the alternatives for every dev package: e.g.,
libfoo2-dev v.s. libfoo3-dev, sometimes there is also a virtual
pacakge libfoo-dev which depends on the latest libfooX-dev, etc.
- verifying that you don't build-depend on a build-essential package
(I suppose you shouldn't build-depend on essential packages either).
And then trying a build with pbuilder to make sure you didn't forget
anything. As someone already mentioned in this thread, I believe,
comparing the Depends: fields of the package built by pbuilder and of
the package built on your system is also useful, since it can help you
detect components that were used for the build on your usual system
because of configure script auto-detection or some such but were not
*necessary* for the build to succeed and indeed weren't use for the
build in the pbuilder chroot.
I short, if you are not willing to do this little work, I cannot see how
you could decently consider submitting the package for inclusion in
Debian since everyone could do the same with checkinstall.
Note: for those who don't read, "you" is not Sven...
--
Florent
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
|
| You can try dpkg-depcheck from the devscripts package that
should give you a first approximation of correct build-depends,
by looking at strace output.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|