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

Re: RFS: iulib (5th attempt)



Hi Charles,

2009/7/19 Charles Plessy <plessy@debian.org>:
> our tools do not invoke the build target twice in a row, but real people
> sometimes have a good reason to do. For instance, I tried to build iulib it did
> not work because I was missing dependancies, and when I installed them and
> called the build target again, it triggered the bug discussed above. A good
> makefile should be resilient to this.

How did you do this? Simply running

$ ./debian/rules build

a second time, produces:

dh --with quilt build

and dh knows it isn't necessary and doesn't build.

> Talking about dependancies, since there are only three versions of the libtool
> package in circulation, you can probably depend on versions higher than Lenny.
> Alternatively, you can support both: it looks easy. It would be especially
> useful if you think that there are chances your package would be backported.
> If the scons migration for the 0.4 version implies to drop libtool, you do not
> need to put too much energy into this…

The latter. I want to get a clean package into the NEW queue, and
while it sits there, I'll work on v0.4.

> A much more problematic issue is the binary dependancies of libiulib0. You have
> devised a long list by hand, but it is not accurate for Sid, which is the
> target of your package. There is at least one error: libavcodec51 does not
> exist there. Do you have evidence that ${shlibs:Depends} is not enough?

No. I've removed everything but ${shlibs:Depends}, ${misc:Depends}

> Probably. Maybe you can submit a whishlist bug, or if you have time, try to
> write such a check.

Done[1,2].

> PS: do you know how to write a symbols control file? (me not).

dpkg-gensymbols -O -plibiulib0

gives me output... But how to know I am using it correctly...

I've uploaded the updated package to mentors.

Regards

Jeff

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537768
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=537769


Reply to: