On Thu, 21 Jan 2010 19:32:20 +0100 Goswin von Brederlow <goswin-v-b@web.de> wrote: > > Presumably your new apt-hookma is in /usr/sbin/ rather than /usr/bin > > like apt-cross? > > No, it just adds /etc/apt/apt.conf.d/00apt-hookma to insert itself > into libapt. The user then uses the normal apt-get, aptitude or > synaptic and -cross support is totaly transparent. OK - wish we could have done that originally instead of the whole apt-cross codebase. :-( It should be easy to check for that file and enable the changes in the branch I've just created. If it is as small as that, maybe we could then add it into apt-cross itself. Maybe - have a go with the test branch. > I have to test how they behave if you have both installed. It might be > that my /etc/apt/apt.conf.d/00apt-hookma sniplet has an adverse affect > on apt-cross. I don't know if apt-cross overrides the apt.conf.d dir. It does not - it does it all via ~/.apt-cross/ > > Scripts need the following functionality (not necessarily using this > > syntax or these options): > > > > 1. $ sudo apt-foo -a armel build-deps PACKAGE > > Could that be 'apt-get build-deps PACKAGE-armel-cross'? That I can > feed into the apt database now. Anything else will need the proper > syntax implemented in apt itself and that can take a while. Yes, it could migrate to that - currently dpkg-cross adds the -armel-cross much, much later. > > 2. $ apt-cache search [a given once we can use the main system apt] > > Yep. Works flawlessly. Too well actualy as apt-cache search for any > library will give you every entry once per configured architecture. > Something that will go away when the -cross names are dropped though. Could cause a bit of confusion - some routines don't use 'grep -m1' or similar. Not beyond the reach of a few tweaks though. > > 3. $ sudo apt-get -a armel install PACKAGE > > Like 1 that is 'apt-get install PACKAGE-arm-cross' for now. When > multiarch support is there and multiarchified packages then the > proposed syntax is 'apt-get install PACKAGE:armel'. OK. > > 3. $ apt-get -o Apt::DownloadOnly=true install PACKAGE > > Now that is a tricky one (You know about -d, --download-only, right?). Yes, I'm just giving the syntax used inside the module which passes the -o directly. > While this will download packages and rename the files it will not > convert them. So 'apt-get -d install libfoo-armel-cross' will download > libfoo_1.2-3_armel.deb and rename it to > libfoo-armel-cross_1.2-3_all.deb. But it will still be the orginial > arm deb. The conversion only happens when the package is actually > installed. Download is probably only needed for emchain and I think we can get rid of that functionality once the toolchains install cleanly from Debian. > Later we should probably have a session to talk about usage other than > installing/upgrading like this and see wether there already is a good > way to do it or if some small tool should be added to automate the > job. But let me finish the current "install & upgrade" work first > before you sidetrack me. :-) > For Build-Depends it might be good idea to install both the native and > cross package though. So > Build-Depends: automake, libfoo-dev (>= 1.2-3) > becomes > Build-Depends: automake, libfoo-dev (>= 1.2-3), > libfoo-dev-armel-cross (>= 1.2-3) That would solve the problem of > tools in library packages. If libfoo is not multiarch-compliant, that makes this transition one-way because I'm pretty sure apt-cross won't be able to cope with the results. Not sure if that's a bad thing or not. > The only critical thing is that any renaming must be able to work > on the Packages.gz file and the DEBIAN/control file inside the > debs in exactly the same way and on Sources.gz on their own. You > can not use information from the debian/xcontrol file unless those are > put into the Sources.gz file in some way. So "apt-get build-dep" might > not give you 100% of what debian/xcontrol later says it needs. Ouch. The only way to know is to test. > Yes. I'm coming from the runtime side of things. The last 2 years I've > used this to run 32bit apps on amd64. I'm just now adopting it to > cross compiling because it already did like 95% of the job for it. The > support for apt-get build-dep is completly new and verry much > experimental. If it doesn't work right from the start then I have to > see if it can be fixed or if it is a lost cause. Worst case you do > start a cross compile, take the list of missing Build-Depends and > apt-get install them. I do that often enough with native packages that > I wouldn't notice a difference. Yes, once apt can understand "-a armel build-dep" then the tools can check and add that if necessary. > > It *might* be possible to convert the libcache-apt-perl module to > > get data from the main system apt cache - at least as an interim > > measure. (It would have to abandon all attempts to update the main > > apt cache with apt-get update so that scripts can continue to > > operate without sudo but I think I can add a new function that > > disables the relevant components.) > > The way apt itself does this is that it checks if the cache is current > and if not it creates a new one in memory. Shouldn't the perl module > be able to do the same? It's currently not the main apt cache so it's not as up to date as the main one. The branch changes could improve that. -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp2Z_1aOGpRX.pgp
Description: PGP signature