[Pkg-ia32-libs-maintainers] ia32-alsa-lib_1.0.16-2+2_ia64.changes REJECTED
Goswin von Brederlow
goswin-v-b at web.de
Sat Apr 26 16:52:31 UTC 2008
Joerg Jaspert <ftpmaster at debian.org> writes:
> Hi Maintainer,
>
> rejected. Good god.
>
> - One of the first points is - you overwrite / jump into other packages
> namespace with this.
> Source: ia32-alsa-lib
> Binary: lib32asound2
> lib32asound2 is built by alsa-lib (for amd64).
> If this is ever going to happen like this you need to have a namespace
> that doesnt kick out existing packages. Or show, in whatever way, that
> the maintainers of the package you want to convert actually do want to
> hand it over to you.
The lib32asound2 package from alsa-lib is only available on amd64.
The lib32asound2 package from ia32-alsa-lib is only availbale on ia64.
Both are API and ABI compatible as they are actualy compiled from the
same source. Ia64 just can't compile it directly.
The reason for the same name is so that Depends, Build-Depends,
Provides, Conflicts, Replaces fields can be unique on both archs.
Also if ia64 ever gets toolchain support the package can just be taken
over by their actual source.
Does this pose any technical problem for DAK? I thought the packages
being for different architectures would keep DAK happy and both
packages in the archive.
> - The included complete copy of the source *and* the existing i386
> binary is something that is really bad. Yes, we get in trouble if we
> don't include the source for packages on the archive, but it is still
> a *very* strong point against this packaging scheme.
> We (as in ftp-team), but even more the security team are against them.
Then we have to remove ia32-libs and ia32-libs-gtk from the archive
and discontinu 32bit legacy support for amd64 and ia64.
> - How about you do not provide the ia32-foo packages yourself, but leave
> that to the maintainers? Just provide the tools to *easily* create
> them at build time. That would be the best way to go. It would enable
> basically every package (where it makes sense) to have an ia32
> version, do not double the source code needlessly, etc. Win win.
The goal is to get the maintainers to also maintain the ia32-*
packages once they are running. So uploads of the plain and ia32-*
package happen near simultaneous. The format would remain though until
multiarch gets implemented.
They can not currently be created at build time. The 32bit libraries
have to be build on i386 but the ia32-* packages are for amd64 (with
the exceptions uploaded so far) and ia64. Building them breaks at
several points (correct me when I'm wrong):
- dpkg-gencontrol: amd64/ia64 packages are not added to debian/files
- dpkg-genchanges: if added to debian/files the Architecture field
in changes still comes out i386 [source] causing a
rejection because the changes file contains
packages for architectures not listed.
- buildd: buildd would most likely be confused by a
libfoo_1.2-3_i386_amd64_ia64.changes file
- dak: not sure what DAK will do with multiple uploads for an arch:
libfoo_1.2-3_i386_amd64_ia64.changes from i386
libfoo_1.2-3_amd64.changes from amd64
libfoo_1.2-3_ia64.changes from ia64
- wanna-build: uploading libfoo_1.2-3_i386_amd64_ia64.changes confuses
wanna-build into thinking amd64 and ia64 have the
package installed so they would no longer build the
native libs
They could be created as Architecture: all packages but that would
require the maintainer to always build them on i386 and building
without -B would fail on all other archs (or be incomplete). I'm not
sure if that is an acceptable way to go.
> - Besides the above points I got a mail a day ago about your packages,
> which I quote (almost) completly, giving some more reasons why the
> packages aren't accepted right now (and point #3 is really WTF!):
>
> 1/ No toolchain support
>
> We already build a hppa64 cross compiler on hppa, a spu-elf
> cross-compiler on powerpc and ppc64, and some biarched libs for amd64,
> i386, kfreebsd-amd64, mips, mipsel, powerpc, ppc64, s390, sparc. We
> support building a hppa64 kernel on a 32-bit hppa kernel, we support
> building SPU (Cell) binaries on any powerpc, we support building 64-bit
> binaries on all biarched 32-bit arch (and even running it if there is a
> 64-bit kernel) and building and running 32-bit binaries on all biarched
> 64-bit arch. But we don't support ia6432 biarch at all. There is no
> cross-compiler built, and no "native" way to build ia32 binaries on
> ia64. If they were, the packages from ia32-gcc-4.3 would be provided by
> gcc-4.3, the packages from ia32-glibc would be provided by glibc.
Which is the reason ia32-libs was created in the first place. To fill
at least the void for users needing to run programms.
> 2/ The source packages include the source packages from which they use
> binaries
>
> Which mean ia32-gcc-4.3 includes the .dsc, .diff.gz and .orig.tar.gz
> from gcc-4.3, same for other ia32-* packages. In short, this bloats the
> archive. Just for the record:
>
> 43M gcc-4.3_4.3.0.orig.tar.gz
> 15M glibc_2.7.orig.tar.gz
f6af1e689c7e4755c5a464df7acae45e 736 ia32-libs_2.3.dsc
9ed6e0bb9b7e57a29614e8a90f4da9af 397313859 ia32-libs_2.3.tar.gz
1af71b32b3f2c60b27e65e4a00d05fb0 671 ia32-libs-gtk_2.1.dsc
604c278619173bc20d43ee7d05c3965e 47247878 ia32-libs-gtk_2.1.tar.gz
No change there. It just gets split into managable pices.
> The solution here would be to provide a tool which is able to live get
> i386 binaries, build ia64 (or even arch:all) packages from them, and
> propose to install them. Having those binaries twice with the sources
> twice in the archive is totally pointless.
That won't work on buildds as a Build-Depends can't fetch packages as
needed. The wine maintainer wants to compile wine on amd64 and I want
to support that.
Preinstalling the tool on the buildds also won't help as they use
apt/dpkg from outside the buildd chroot and that can't do on-the-fly
conversion due to a missing features in apt. I tried writing just such
a tool as you propose and got stuck when I needed support in apt to
update it's package database after the tool did its renaming of packages.
Maybe after lenny we can do this as stable apt then has support for it.
> 3/ No README.Debian
>
> There is no indication whether how to run ia32 binaries on ia64, so no
> indication whether how to use those packages. I asked Goswin von
> Brederlow if he knew how to run them. He doesn't know. I asked him how
> did he tested the packages, he answered that someone (he can't remember
> who) told him on #debian-devel it worked.
When he asked that was the first time I ever heard that starting 32bit
binaries on ia64 is not straight forward. The kernel has support for
it so I assumed that you just start the binary like any other, just
like it is on amd64. I don't have access to any ia64 and nobody ever
asked before in the years since ia32-libs exists.
I totaly agree that this should be documented but that will need an
ia64 user to write it. I will ask on debian-ia64 for someone. But
again something that is already present in ia32-libs.
> 4/ Hard to handle for security team
>
> Those packages are not built from sources. This make them hard to handle
> for the security team.
One goal of the split is to simplify the handling. Currently all libs
are combined in ia32-libs and ia32-libs-gtk and even noticing if any
of them is affected by a security upload is a problem. With the split
packages there is a simple 1:1 mapping of the name so it is trivial to
check if ia32-foo exists when foo is updated. The package can then be
updated using "debian/rules update" or by replacing the tar+dsc+debs in
the source and adding a changelog entry.
The split also allows to use correct shlibs (and soon symbols) files
to track the inter package dependencies instead of always depending on
the latest version. So specific libraries can be updated as needed
without causing a ~500MB upload.
> 5/ Uploaders filed
>
> Maintainers and Uploaders from $foo package are added to ia32-$foo's
> Uploaders without noticing them. I'm not quite sure Aurelien Jarno wants
> to maintain ia32-glibc. I'm not quite sure Matthias Klose wants to
> maintain ia32-gcc-4.3.
Easy enough to change. I included the original maintainer and
uploaders to indicate that they are welcome to upload an updated
version without it being a NMU.
> --
> bye Joerg
I can change the name (if needed) and the uploaders field easily enough.
Apart from that I don't see any of the reasons as relevant for the
package split. They all already apply equally, if not more so, to the
existing ia32-libs and ia32-libs-gtk package.
So does it make sense for me to fix the two relevant reasons and reupload?
As for reasons why you should let the packages in: http://popcon.debian.org/
amd64 : 10988
ia64 : 53
------
11041
#rank name inst vote old recent no-files
988 ia32-libs 10371 267 2320 2268 5516
In percent: 94% of all popcon users for the relevant architectures
have the package installed.
MfG
Goswin
More information about the Pkg-ia32-libs-maintainers
mailing list