Re: dpkg-cross
Hello Nikita,
Well I'll try to answer all your questions as good as I possibly can (without
having to spend to much time on looking everything up). So if I miss something
or just don't give you enough explainations just ask me (maybe that happens
better off-list)
Quoting "Nikita V. Youshchenko" <yoush@cs.msu.su>:
> Seems that changes (over 1.14) are:
>
> - - -Emdb command line switch added; it just sets 'emdebian' environment
> variable to 'true', and does nothing more (it also sets perl variable
> $emdebian, but it is not used anywhere)
This variable is used by several dpkg-... tools to select the right files in
the source package. (look at dpkg-checkbuilddeps for example). Basically it
makes it possible to choose between the information in the normal location
debian/... and emdebian/... (it is very important to use the correct rules en
control file,...)
> - - $crossprefix configuration parameter is exported to environment variable
>
> CROSSPREFIX
I don't think I added that, I believe it was already there
> - - $extraflags configuration parameter added, and exported to environment
> variable EXTRA_CFLAGS
The idea was to be able to use extra needed compiler flags, depending on your
hardware or optimalizations you want. (for example -msoft-float)
> - - $library configuration parameter added, and exported to environment
> variable LIBC
This one is used to get the name of the package straight, and also its
dependencies. As such a emdebian package compiled with glibc has a different
name from one compiled with uclibc and also depends on emdebian glibc
packages.
> - - $config configuration parameter added, and exported to environment
> variable CONFIG
For some programs or tools it is interesting to be able to manually override
the default configuration. This config variable does just that. Take the
busybox package for example. It has a nice ncurses interface for
configuration. Depending on your intended use it might be interesting to adapt
it to your needs. However the debian policy states a package should have a
standard configuration to be able to compile it with a autobuilder and to
reproduce bugs. This is more or less a way to be able to do both.
> I may easilly incorporate those into dpkg-cross 1.14.6.
> However, first I'd like to get some comments on the following.
> - - I can't get what's that new -Emdb switch for (just setting 'emdebian'
>env> variable?);
correct, for its use see earlier
> - - $library and $config are not the best names for configuration
parameters:
I gave those names because it exactly describes what they are meant to do. See
earlier also.
> it's difficult to guess what these names mean; probably LIBC should be set
> to $libc? And what's CONFIG for, I can't guess ...
> - - cross-compile(5) manpage should be updated.
I could have messed it up a little there. I had to learn about 12 programming
and scripting languages in the last 8 months so I don't know even one well
enough to avoid stupid mistakes. I could have messed some things when trying
to find a way to let perl and bash work together.
> 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. However you will still need to hack up some devscripts.
> One more thing with stag-addons: it provides some non-null information
> in /var/lib/dpkg-embed/info and /var/lib/dpkg-embed/alternatives; this
> information is not consistent with what is in /var/lib/dpkg-embed/status.
> That's strange.
Apparently I made a mistake there when packaging it probabely. It is just
there to be able to use a seperate package database for your development host
and your target system. (I had some nasty surprise when I overlooked that.
Removing busybox and getting system files like init removed :) )
> And about stag-get: it seems that it replaces /etc/apt/sources.list and
> other files for a time; I believe it's a very bad idea, because it will
> left host system broken if it's interrupted. Probably some games with trap
> shell builtin may make situation a bit better, but still it will be unsafe.
> On the other hand, apt allows to redefine almost any parameter in command
> line or in a configuration file! You may make it to use other files
> instead of /etc/apt/sources.list, /var/cache/apt/*, etc, etc
> I believe this should be used instead of altering important system
> configuration files...
I wrote that do do some quick test. It should indeed be re-implemented.
Because of the reasons you mention, but also because of the limitations of the
current wrapper, you can for example only select one package at a time. I
howver did not find an option to let apt use other files, I probabely
overlooked them.
To also answer your question about the compiler support. Well I did that some
months ago and couldn't immediately find where it had to be adapted.
Anyway let me acknowledge your great work, thanks,
Philippe
| Philippe De Swert -GNU/linux - uClinux freak-
|
| Stag developer http://stag.mind.be/
| Emdebian developer: http://www.emdebian.org
|
| Please do not send me documents in a closed format. (*.doc,*.xls,*.ppt)
| Use the open alternatives. (*.pdf,*.ps,*.html,*.txt)
| Why? http://pallieter.is-a-geek.org:7832/~johan/word/english/
--------------------------------------------------------------------------
Gestuurd via het webmailsysteem van het De Nayer Instituut: www.denayer.be
Reply to: