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

Re: dpkg-cross

+++ Nikita V. Youshchenko [04-06-03 01:35 +0400]:
> Hash: SHA1
> > > Maybe it's better to create a more general solution? What comes to
> > > mind:
> > >
> > > - - allow /etc/dpkg/cross-compile to define ANY environment variables
> > > directly in /etc/dpkg/cross-compile;
> > >
> > > - - or even more general: dpkg-buildpackage wrapper will get a "mode"
> > > parameter (e.g. -m MODE); /etc/dpkg/cross-compile will have "mode
> > > sections", that define, which environment variables should be set in
> > > which mode; so one mode will be used for emdebian, other mode for
> > > debian packages cross-compiling, others for something else ...
> > >
> > > Isn't that a better solution that your changes? This may be
> > > implemented in half-an-our, and won't require a rewrite when tomorrow
> > > you will need some more environment variables.
> >
> > My approach gradually grew by trail and error, so it got implemented the
> > way it looks now. Well there are certainly some very good things about
> > your approach.
> I've implemented that, and uploaded dpkg-cross 1.14.6 to 
> http://zigzag.lvk.cs.msu.su/~nikita/debian/
> Changelog is 
> dpkg-cross (1.14.6) unstable; urgency=low
>  * debian/rules: move commands from binary-arch to binary-indep (everything
>    built is architecture-independent)
>  * debian/rules: don't run dh_strip and dh_shlibdeps - both are useless for
>    this package
>  * Implemented enhanced addition variable setting control, after some
>    discussion with EmDebian people. See cross-compile(5) for more
>    information. Note that the new format of this file is completely
>    backward-compatable.
>    Example of usage for EmDebian added as a comment to the default
>    /etc/dpkg/cross-compile file.

OK, I've had a look at this, with a view to removing dpkg-buildpackage and
dpkg-shlibdeps from stag-addons and depending on this new version of
dpkg-cross (which also fixes a problem that stag-addons version of
dpkg-buildpackages overwrites the diverted copy of dpkg-buildpackage not the
normal one, which breaks things quite badly).

And whilst I can see that the 'mode' scheme in dpkg-buildpackage gives the
same (better in fact) functionality as in the emdebian version, I don't see
how your new dpkg-shlibdeps replaces the necessary code in the emdebian
version. Am I failing to understand the versatility of your scheme, or do we
need to merge this somehow?

Currently the paths for $shlibslocal and $varlistfile are set to
./emdebian/blah instead of ./debian/blah when the $emdebian environment
variable is true. How do we get shlibdeps to do this
given that we can set environment variables or makeflags, but I don't see
how either of these are going to change the files that dpkg-shlibdeps reads?

It could be passed these things as options, but I don't know whether it
always will be when it is invoked.

If we can get this bit right then I think we have quite a pleasing solution
(I've done the creating /var/cache/dpkg-embed dir in postinst stuff, and
made dpkg-stag create somewhere to put it's version of the available files
automatically if necessary)

Aleph One Ltd, Bottisham, CAMBRIDGE, CB5 9BA, UK  Tel +44 (0) 1223 811679
work: http://www.aleph1.co.uk/     play: http://www.chaos.org.uk/~wookey/

Reply to: