Javier Serrano Polo <[EMAIL PROTECTED]> writes:
> It looks like Goswin's been working on a similar approach:
> ia32-libs-tools.
>
> See
> http://lists.gag.com/pipermail/debian-ia32-libs/2008-February/000362.html
>
> I'll add some comments comparing both techniques.
>
> My idea was to make some kind of extra section/branch/whatever in a
> repository. For example, in my local repository I build amd64 packages
> from downloaded i386 ones. A multiarch repository (ftp.debian.org) would
> use packages from the local filesystem. There's no need to create source
> packages therefore.
I have such a repository for sarge. But I also convert amd64 package
while keeping the 32bit packages pristine, but only because i386 is
official in sarge. My conversion moves 64bit libraries for lib64, adds
diversions and alternatives for binaries and include files and
whatever else is needed. I have a repository of some 600+ packages
made this way.
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. 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?
If you take the Packages.gz from i386, change the Architecture fields
to amd64 and rename the packages from libfoo to ia32-libfoo (or
libfoo-i386), put it into /var/lib/apt/lists/ and get apt to use them
then it will dutifully download i386 debs for you and pass them on to
dpkg. You can do that by replacing apt with a wrapper that catches
"apt-get update" calls and runs them for i386 and native arch and
merges the results.
Next step the dpkg will fail to install the i386 debs as they aren't
converted for use. So you replace dpkg-deb with a wrapper that checks
if the deb in question is an i386 deb and, if so, do the conversion
first. Actualy there are 2 cases: 1) extraing the meta infos, 2)
extracting the data.tar.gz.
> Another topic's the maintainer's involvement. I think they should be
> left out. It's difficult enough to maintain a package, more if they must
> consider multiarch support and specially if they don't have access to
> the arch in question.
For most source updates the conversion remains the same. 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.
> When using several packages (instead of ia32-libs) the problem is
> reduced to dealing with dependencies, many of them easily automated.
> This could be handled by ia32-libs maintainers. Of course, the package
> maintainer may know the best (multiarch) dependency relationships.
>
> The overall point is to be as unobstructive as possible. The only
> changes would be in i386-only applications, that would use alternative
> development libraries.
>
> Goswin's using the ia32- prefix while I use the -i386 suffix (as in
> libc6-i386). The latter's been helpful during development
> (version/section/naming comparisons).
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.
> In my scheme, dependencies on native packages are only made when file
> conflicts would occur. This happens a lot in development libraries. The
> goal again is to be less obstructive. Besides, 32-bit libraries should
> be able to be installed independently; they run independently.
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/*.
> Regarding my scripts, they aren't as efficient as I'd like but they get
> their job done. I could deploy the repository right now if I had the
> bandwidth (and signed the files). Supporting the applications I
> mentioned before means ~29MB, 146 packages.
MfG
Goswin
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
