[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

     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++
     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


Reply to: