> - - bad default for crossbase (it *should* be /usr, there is no point to make > it different unless toolchain is able to handle that) - this may be fixed > immidiatly A default to /usr seams to be ok for me. The possiblity to change crossbase is mandatory for all the foraign toolchains e.g. HardHat where crossbase have to be set to /opt/hardhat/devkit/ppc/8xx. > - - the cause of probalem was that user config overrides completely system > conffile. Raphael, what do you think about proposed patch? it is safe? Or > probably we should postpone better config handling until dpkg-cross 2.0, > where such functionality is planned anyway? The problem is not in the possibility to extend. If you have the possibility to extend the /etc/dpkg/cross-compile file with ~/.dpkg/cross-compile you need also a way to reset to default or a way to unset variables, packates etc. Considering the ongoing freeze of Debian 3.1 I won't change to much thinks yet. We should wait until 2.x of dpkg-cross with a rewrite of the configuration to address the issue with the required time and quality assurance. > - - dependences can't track situation when different -arch-cross packages use > different paths. Looks that any combination of -arch-cross packages with > different paths is broken if installed in the same system. I see two > possible solutions here: > *) in postinst of -arch-cross packages, ensure that paths in the current > package and in dependent packages are the same, make installation fail if > they are not; add path check code to anything that use -arch-cross > packages (e.g. to cross-gcc building scripts). > *) if paths are non-default, encode path information info package name > suffix; so -powerpc-cross will always have files under /usr/powerpc-linux, > and if someone needs a package with files elsewhere, that package will > have different (probably somewhat long) name > Second solution looks better for me. For me too. I will prefer the second solution because it less error prone and will work very nice with foreign toolchains too ;) Today you have to be very careful not to mistake the same package compiled with two different toolchains. Different postfix names would be a big improvement here. -- Raphael Bossek
Attachment:
pgpq7qsUHWwrQ.pgp
Description: PGP signature