Re: [MoM] Any student for June?
On Mon, Jun 04, 2012 at 05:51:13PM +0200, Eric MAEKER wrote:
> We have two "natural" ways to build the source and create the package:
> - the upstream natural way is to add some params to the qmake command line (what I've done). This way three simple commands are needed (qmake, make, make install). Using a simple patch, I can even try to build release and debug libs in one command.
I'd prefer the non-patchy way because it is more easy to maintain. If I
understand correctly when using qmake instead of say automake the qmake
takes over the role of configure, right? This seems to perfectly fit
the fact that you have overriden dh_auto_configure - so this is fine.
I'm perfectly new to qmake - so I'm also a bit guessing what might be
the proper way to go. However, after doing some reasearch about dh and
qmake I think the best way to go would be:
dh $@ --buildsystem=qmake
Would you like to test this to possibly profit from other automatic
adjustments (like perhaps hardening flags etc which might be set that
way - I have not tried, just speculating).
> - the d-shlibs way which seems to be natural in the Debian packaging world. I can not find any documentation about d-shlibs with google. May be you can send me some links ?
>
> As I am not a Debian guru, I will follow you choice (my preference is to use qmake).
This is definitely a total missunderstanding of the role d-shlibs is
playing. It comes *after* the make install step so it is no replacement
for qmake at all. After you did a make install $(CURDIR)/debian/tmp
d-shlibs takes over and verifies that files will end up in the right
location and that debian/control contains the proper names and
Dependency relations.
> Ok, give it a test and let me know. I did not work on symbol versioning as I did not understand anything to this matter...
So d-shlibs is definitely for you because *it* understands this matter
and is checking for you that everything is fine. (Guess why I'm using
it. ;-))
> I've adapted the freemedforms code to take into account the availability of the libquazip package. Using the qmake command you can define if you want or not to use the packaged lib (in this case, libquazip is not built by freemedforms otherwise it is). Then I tested the lib with freemedforms and did not experiment any problem (I have just to check that my freemedforms build used the headers of the packaged libquazip).
Hmmm, did the package build at your site as it was commited. IMHO SVN
commits r11202 and r11204 are definitely needed to build the package at
all. I can not imagine that you was able to build it without these
changes. Understanding r11202 is specifically important to understand
Debian packaging. (Please tell me if it remains unclear to you.)
Moreover the doc package is empty. I made a very stupid typo when
injecting it. Do you see the problem? That's your training task -
seeking for such bugs is a good training (and no I do not make such
errors intentionally and took me also some time to see what's wrong).
> Ah ah ah... Good... We are exactly "on the same radiowave" :) Yesterday I started to write you a private mail to ask you about updating the svn path to libquazip as well as the source package name.
Hups, do not remember, but fine if it is that way.
> I've done the change.
Good.
> > name the source package (in changelog and control) from quazip
> > to libquazip.
>
> done too.
Only have done -> r11202.
> > Saying this I would like to mention that I added you as MoM student for
> > month June. Thanks for your readiness.
>
> Thanks,
Thanks for your work
Andreas.
--
http://fam-tille.de
Reply to: