On Tue, 19 Jan 2010 23:21:17 +0100 Goswin von Brederlow <goswin-v-b@web.de> wrote: > >> I've been working on a next generation apt/dpkg-cross that will > >> support apt, aptitude, synaptic (anything libapt based) and dpkg > >> directly. > > > > Why? There is no future for apt-cross or dpkg-cross - there should > > be no next generation. We get through the multiarch transition and > > both dpkg-cross and apt-cross disappear for GOOD. > > Why? Because dpkg-cross didn't do enough for running 32bit binaries on > amd64 and apt-cross was, well, apt-cross. :) The multiarch transition > will be a lengthy process so there is still a few years use left in > this. As long as we're clear that we're both talking about interim measures and that the goal is that all this stuff goes away. If you're talking about your apt-cross and I'm talking about the apt-cross in Debian, things are going to get missed. Can we define the terms? Are you talking about fixes in apt that replace apt-cross (or allow apt to work with full multiarch and therefore make apt-cross redundant) or are you talking about yet another script that tries to work around the brokenness in apt? > >> - Wrappers in /usr/lib/apt-cross/. Add that dir to your PATH or > >> link them from /usr/local/bin and you can install foreign packages > >> transparently with just dpkg. This has some sideeffects so maybe > >> don't use this. > > > > I can't see that as a good idea but I also don't see why it is > > considered necessary. /usr/lib/apt-cross/ is the wrong name. It has > > to be a name based on an arch triplet, but we're already using > > those. > > Sorry, I ment /usr/share/apt-cross/. Nothing arch specific in there. So these would be shell or perl scripts? > >> - apt-get, aptitude, synaptic (anything libapt based) are > >> automatically setup to support -cross packages (just needs > >> configuration to know which archs). > > > > This is the main area of work, but not for -cross packages, for true > > multiarch packages. > > I find those verry important to upgrade. Having to download all debs > and dpkg-cross -i them would be horrible. This is precisely the problem that the new updates for apt-cross and dpkg-cross try to solve - by populating that suite-specific list of packages that are multiarch-compliant and not creating dependencies on native packages from -cross packages unless those native packages are multiarch-compliant. We must avoid having -cross packages depending on non-multiarched native packages - even the dummy -cross ones. Arch:all is fine. > > dpkg has to do that, not dpkg-cross. > > > > Why are we still looking at -cross packages? > > Because it will be years before no more -cross packages are needed. Increasingly, -cross packages will become empty dummy packages though. I know it's going to take longer than I'd hoped. > alternative. I would expect "apt-get -o Apt::Architecture=armel ..." > to cause apt-get to consider armel the native architecture. You'd think that but from what I've done with apt-cross, apt does seem to leave that job to dpkg. i.e. if a binary-dependent armel package depends on a binary-independent all package, apt handles it correctly whether the machine is native armel or native amd64. What's been missing is how to get apt to do that *after* we've mangled the package names by adding '$arch-cross'. Once we stop doing that, apt is just fine with the dependency resolution in download mode. (See multistrap.) Once we fix that and get dpkg to be able to install the downloaded .debs, apt can take over from apt-cross. > That would > likely try to install make:arm instead of make:<native> then for > example. That's what would be needed - once make is multiarch-compliant. As long as the armel make executable gets put into /usr/bin/$triplet (or $triplet/usr/bin or /usr/$triplet/bin) or thrown away, that's fine. > >> Last there is also a tool (convert-cross) to convert deb packages > >> instead of installing them. The same mechanisms used during install > >> (see implementation below) are used to convert libfoo_1.2-3_arm.deb > >> into libfoo-arm-cross_1.2-3_all.deb (or a dummy > >> libfoo-arm-cross_1.2-3_arm.deb if multiarch). Those packages can > >> then be put into a repository and installed with plain apt and > >> dpkg. Those that don't like on-the-fly conversion can use that to > >> get identical results. > > > > Please can we get rid of all -cross ideas? The whole point of > > multiarch is that all -cross stuff goes away. > > I would love nothing more but I don't see it done yet. OK then, I'm not sure what convert-cross needs to do that dpkg-cross and apt-cross do not do now. With the current changes, libfoo would be handled as you describe above - except that these are local packages. That's the whole problem with having -cross anything in the package name, it breaks all this stuff. We need to stop renaming packages ASAP. > > apt needs to be taught how to keep multiple lists safely - changing > > arch causes apt to delete all lists for the other arch, changing > > back removes them again. Some of the problems with apt-cross are > > because apt-cross tries to stop apt doing this and then the apt > > bindings get confused. > > That is included in the patch already. It adds the arch to the > filename of index files. Good! (except that is going to break apt-cross really, really badly.) :-| > >> /etc/apt-cross/black.list: > >> > >> Filter blacklisting packages from conversion. By default this > >> prevents any binary available natively to be converted. > > > > ? There is support in the MultiArch Spec for such limitations, why a > > separate one? > > Is there? https://wiki.ubuntu.com/MultiarchSpec doesn't list any that > I saw. Why doesn't Multi-Arch: foreign cover those? (It shouldn't be /etc/apt-cross - possibly /etc/multiarch/ or /etc/apt/multiarch.d/) > The black.list is a security precaution preventing the user to shoot > himself in the foot in obvious ways. While it should work to install a > 32bit bash on amd64 that is normaly not desired so the default > black.list prevents experiments like that. It also prevents > apt/aptitude/synaptic from going crazy with e.g. type-handling. Having > type-handling from multiple architectures confuses the hell out of > apt. The blacklist might be a safeguard for executables 32/64bit but I'm not convinced it's needed for cross-building. If the package is fully Multi-arch compliant, shouldn't the foreign executable be put somewhere other that /usr/bin ? If it isn't multiarch compliant, what's it doing declaring Multi-Arch: foreign? > >> It further explicitly > >> excludes dpkg, apt, aptitude, type-handling and a few more from > >> ever being converted. > > > > That won't work. apt provides a SONAME that needs to be available as > > armel when cross-building things like aptitude. apt does need to be > > installed as a multiarch package. > > In the long run apt needs to be split into apt and libapt for > that. You can't install an apt:arm on amd64 as that would give you a > non-functioning /usr/bin/apt. And even if it would work it would > suddenly install arm packages natively across the board and refuse to > install amd64. I'm getting confused - I thought the point of this was that a Multiarch: same puts it's files in places where this is no conflict with the native files. That conflict would include not being in PATH. i.e. a multiarched dpkg will do what dpkg-cross currently does and move things around to avoid conflicts and replacements. Prior to that, dpkg-cross works as normal - with the changes I'm uploading tomorrow. > > Umm, it works OK if the installation locations are done properly. > > The current apt-armel-cross package IS a necessary one. > > But that is because you only handle libraries. My use case also > includes handling foreign binaries. OK - wasn't there the idea of /usr/$triplet/bin or similar? > If apt-armel-cross is really > needed before apt has a multiarchified libapt I have to change > something to support that. Do you remember why you needed it? It is because apt thinks it is a library. apt-armel-cross doesn't contain apt itself, just the libapt-pkg library. > I can call it apt-cross-ng if you like to make clear it is a different > package than apt-cross. It's not a different package that causes me to ask, it's that it's a multiarch interim step, not a cross. I don't want things like this delaying the removal of apt-cross. That and I find it confusing about what you mean by apt-cross when apt-multiarch would be clearer or whether we're simply talking about fixes within apt itself. > > Why can this not be calculated from the Multi-Arch fields? > > Because when you install libfoo_1.2-3_arm.deb, which Depends: libbar, > you do not have access to the Multi-Arch field of libbar. And libbar > might not be multiarchified yet, which you also don't know. That is why we have the suite-specific list that is coming in the next releases of dpkg-cross and apt-cross. The list tells you if libbar is multiarched or not. Reliably. dpkg-cross will then use that information when considering the Depends: line of libfoo. > > You cannot unpack into /usr/ anything - it has to /tmp or /var/ > > Who said anything about unpacking to /usr? > >> /usr/lib/apt-cross/dpkg-deb is used to unpack debs. Is that a script or an unpacking location? What's a dpkg-deb version doing in /path/apt-cross/ and can't we think of a better place for it? /usr/lib/dpkg/ ? /usr/lib/dpkg-multiarch/ ? I'm trying to see a clear dividing line between -cross - OLD, BAD and multiarch - NEW, GOOD! A dividing line that is consistent across package names, script names, paths, behaviour, the lot. It's going to confuse the hell out of me if people keep talking about -cross when talking about the transition away from -cross. -cross must die! (eventually) dpkg-cross is to be absorbed into a multiarch-competent dpkg. apt-cross is to be replaced by a multiarch-aware apt/aptitude Each is to have an ever-reducing role, migrating from useful packages to empty dummy packages and thence to no packages to process at all. Any new scripts that will outlast either dpkg-cross or apt-cross should not use the -cross name, whether in packages, scripts, conversions or file paths. > > Why? If this is during the transition, we just use dpkg-cross as > > now. If it's after the transition, there should be no need for any > > -cross package. > > Why do this on the fly as opposed to the existing way of creating a > temporary deb and then install that? I don't want to gunzip > data.tar.gz, mangle it, gzip and then have dpkg gunzip again. Doing > this on the fly saves a gzip and gunzip run. Why add another script when what we really need is for dpkg to do the entire job internally? i.e. dpkg will do without the temporary .deb stage. If that is what you proposed, then I misunderstood that section. > >> With --fsys-tarfile first the control.tar.gz file is unpacked and > >> checked if this is a native package, foreign package and if it is > >> multiarch or not. Native packages are left unchanged. Multiarch > >> foreign packages without -cross in the name are also left > >> unchanged. > > > > Why is "foreign" insufficient? Why are we expecting to have -cross > > versions at all? > > Because there will be libfoo-arm-cross dummy packages for as long as > some reverse depends needs it. > Again, just for the years of transition to full multiarch. OK. > >> Multiarch foreign packages with -cross in the name are changed to > >> dummy packages just containing a changelog. Actually they'll contain no files at all, not even a changelog. > And I'm not changing anything there. Just describing it. OK. > >> Non multiarch foreign > >> packages are unpacked to a temporary directory and then files are > >> moved around. Include files to /usr/include/arm-linux-gnu, > >> libraries to /usr/lib/arm-linux-gnu, binaries thrown away and so > >> on the same way dpkg-cross moves files around now (except with > >> multiarch dirs now). If it > >> exists /usr/share/apt-cross/<package>.data is executed to do extra > >> modifications needed. > > > > I don't see how this fits with the changes I've already got pending. > > It should be exactly the changes you have pending. What is /usr/share/apt-cross/package.data about? > > I think you're putting far too much weight onto apt-cross - it > > really, really cannot take it and fixing it is simply not > > reasonable. Forget apt-cross, for multiarch purposes, it simply > > isn't usable, it doesn't exist. dpkg-cross will merely be a set of > > config files in dpkg and -cross packages should not exist, apart > > from those few empty dummy ones from the current pending changes in > > dpkg-cross and apt-cross. > > Sorry, way too late. I've been using this with apt for nearly 2 years > now to run 32bit binaries on amd64 and I don't expect it to be fully > obsolete before squeeze+2 if then. The original amd64+i386 specific > implementation has over 50 users and worked just fine for multiarch > purposes. And I'm 95% done adapting it to work with any arch and for > cross-compile purposes and it would be a shame not to finish it now. > > Note that the only common thing with apt-cross is the name, as it > fullfills its purpose as well as do much more. I agree that the > current apt-cross is unusable and I didn't try to fix it. I just want > to replace it with something that actually works well. It is really confusing to talk of apt-cross when you're thinking of a new script and I'm thinking of the current one. apt-multiarch ? apt-cross can only survive as long as the last reverse dependency is not multiarched. It does need to be replaced but I'm not sure we need another version, rather I think we need to fix apt/aptitude. I'm not clear where your replacement fits in. > I don't want to create work for you. I will maintain and use this > myself and if you don't like it you can keep the old dpkg-cross and > ignore it. And while any -cross package is inferior and "deprecated" > it still is the only usable way for now and the near future. Yes, -cross packages will hang around but I just want to be sure that they aren't going to hang around forever. :-) > The workload of apt-cross is also as reduced as I think it can be as > long as there is dpkg-cross. All it does is run the index files > through the renaming process dpkg-cross does to create the > libfoo-arm-cross packages. As long as there is a dpkg-cross being used > that does that renaming of package names apt-cross has to do the same > to be able to upgrade cross packages. ... if only the life of apt-cross was that simple . . . -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgp72w1udnxit.pgp
Description: PGP signature