Re: ANNOUNCE: usfda-ndc-drug-info v0.4
On 13 May 2003, Elizabeth Barham wrote:
> I ended unpacking the original and moving the whole directory over to
> an "orig" directory, like this:
This is definitela NOT necessary. Just use your upstream tarball whatever
name it has and whatever directory it will put its contents. The simple
link
ln -s usfda-ndc-drug-info-0.4a.tar.gz usfda-ndc-drug-info_0.4a.orig.tar.gz
will do the job if you use dpkg-buildpackage or preferably debuild to build
the package.
> tar xzf usfda-ndc-drug-info-0.4a.tar.gz
> mv usfda-ndc-drug-info-0.4a usfda-ndc-drug-info-0.4a.orig
Not necessary at all because dpkg-buildpackage or debuild are smart enough
to do the job as expected whatever tha name of the drectory is.
> This made the diff automatically which I prefer since I'm also
> providing the original sources and it seems redundant to provide:
>
> usfda-ndc-drug-info-0.4a.tar.gz
> and
> usfda-ndc-drug-info_0.4a-3.orig.tar.gz
NO NO NO. Not this ---------------^^
Just try the symbolic link as above and tell me what happens. If something would
go wrong we have to fix this.
> > 0) You do not need to provide a file named
> > <package>_<upstreamversion>-<packageversion.orig.tar.gz
> > at sourceforge but you should definitely make sure that your build
> > is done with an absolute identical source file. Just use the symbolic
> > link as I did above.
>
> To my understanding, this normally only works on the *-0 or *-1
> release
Yes - and if there is a new upstream source you *have to* provide a new
upstream tarball.
> as you mention in (1) below. Good point, however.
That's why I explained it under 1) in detail.
> My guess this is due to my not providing a build dependency on
> libdb3++ (= 3.2.9-16) and libdb3-dev?
This might be the case but this would not help to get your package into
Debian testing or later into stable.
~> apt-cache policy libdb3++
libdb3++:
Installed: 3.2.9-17
Candidate: 3.2.9-17
Version Table:
*** 3.2.9-17 0
This means you have to build against 3.2.9-17 or later. It is perfectly possible
that this version has a bug. If this is a case you should file a bug report against
this package and explain your problem in detail. Just use the "reportbug" tool
to file bug reports.
BTW, I just tried to build your package in an unstable chroot jail and found out
that you have a missing Build-Dependency from "g++" package. Autobuilders might
cause problems if you would not add this.
> The libxml error seems a little more dire as I'm using the aclocal
> script that came with the package and it #include's:
>
> #include <xmlversion.h>
>
> as where in Debian, this should be
>
> #include <libxml/xmlversion.h>
If you have to change this, than
1. untar your original source archive
2. patch the necessary files
3. debuild -> this will build the diff against the original archive (see above)
> I'll give it another go a little later on.
Sorry that I can't help with the (real) problem with compiling the package.
Kind regards
Andreas.
Reply to: