El dt 12 de 02 del 2008 a les 10:26 +0100, en/na Goswin von Brederlow va escriure: > The ia32-libs-tools is actualy a simplification from this full blown biarch > conversion into something less intrusive. > > But this is actually quite a waste of space.
Not really, this is repository space. 600 packages may be around 120MB, it's nothing compared to the benefits. Converted packages are usually smaller, saving bandwidth. > The conversion is quick > (quick enough that we don't need to cache the result) and totaly > reproducable. So why not do it on the fly? There are packages that build using both 32 and 64 bits software. You need a different namespace to disambiguate dependencies. Besides the space point above, you'd need to convert the package and all its dependencies. Involved mirrors must be synchronized and there's any problem you could imagine with an online process and user preferences. The process is greatly simplified with a ready repository. Dependency handling is well tested and controlled. You don't need to complicate the packaging tools. In this sense, this is backwards compatible and can be implemented right now. > If you take the Packages.gz from i386... This is what our tools are basically doing, right? > You can do that by replacing apt with a wrapper... > Next step the dpkg will fail to install the i386 debs... This is getting really complex. Is this really working for you? I mean, I'm comparing something that's working for me with other method that I don't know if you've finished. > The idea of > getting the maintainer involed is that he/she will update the > ia32-libfoo package the same day he/she updates the libfoo package. As > for fixing problems the ia32-libs team would still be there. > > Think of it this way. The libfoo maintainer becomes a co-maintainer > for the ia32-libfoo package and would do all the normal uploads while > the ia32-libs team would to the bug fixing in the conversion. Dependency exceptions are the main problem with having the conversion inside the build. If the repository manager handles these extra packages, which is fairly easy, no library maintainer is hassled because of multiarch issues. It's somewhat easier to bug "culprit" package (i386 only) maintainers than well ported packages. The point is you mustn't rely on maintainers to do this extra work. Their help is optional, thus unnecessary. Of course, we can start with a separate repository and gradually have maintainers take over these packages in their builds. > I picked ia32- because we have that for ia32-libs, ia32-libs-gtk and > ia32-libs-kde. The -i386 suffix is used by libc6 as libc6-flavour. gcc > uses lib32gcc1, zlib1g also uses lib32z1. > > But the actual name doesn't matter much as long as we don't change it > later. In ia32-libs-tools you just have to change the rename script. I was hoping this could be extensible to other architectures (-powerpc, -sparc, future ones). Apart from that, now that package updates have been automated, the name pick is rather cosmetic. I prefer -i386 to be consistent with other suffixes (-java, -perl), but I wouldn't mind using ia32- except for that extra dependency substitution. > Do you compare the 32bit and 64bit packages to find conflicts or do > you look for files in locations that will probably conflict? E.g. if > there is a file in /usr/bin it will probably conflict. Or in the case > of -dev packages /usr/include/*. I grab the /lib /usr/lib and /usr/share/doc/package basically. Anything else (shared data, configuration) means conflict. If I have convinced you to use repositories, let me know if I should use the ia32- prefix finally. If you want to set it up and use your tool instead, I can share my progress so far. I'll wait a couple of days for your answer. I've already made a successful upgrade from wine using ia32-libs to one using split packages. I'll probably distribute the files using the ed2k network while looking for something better. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
