Re: ia32-libs{-tools}, multiarch, squeeze
Joerg Jaspert <joerg@debian.org> writes:
> Hello world,
>
> (Please remember that we can only speak for ourselves and not the
> security/release/any other teams, individuals or other sentient beings.)
>
> During the recent discussion about about ia32-libs{,-gtk,-tools} there were
> various requests for removal / comments about ftpmaster requirements for the
> whole ia32-libs situation.
>
> Having looked at the situation both in lenny and in sid, we tend to agree that
> ia32-libs-tools in its current form is unacceptable. It was mentioned in the
Please do files bugs about issues you consider blockers for
ia32-libs-tools and squeeze and please include if that applies even if
there is the old ia32-libs in parallel to it (i.e. when it doesn't get
pulled in on upgrades).
> threads that comments had been received from ftpmaster that the lenny form of
> ia32-libs (the one where all the source is duplicated in two huge packages -
> ia32-libs and ia32-libs-gtk) was disliked. This remains the case but it is
> still preferable (both to us, and it seems to the majority of the rest of the
> project) than the ia32-libs-tools approach.
>
> Given that there are definitely use-cases for some form of ia32-libs, we
> suggest that a version of ia32-libs{-gtk} is re-uploaded to Debian, replacing
> the current ia32-libs-tools. This needs agreement with the release and
> security teams, as this most probably will have to be supported for squeeze in
> some form (even if that includes admitting that we have no security support for
> the binary ia32-libs packages).
Also an agreement from Bdale Garbee <bdale@gag.com> and/or Frederik
Schüler <fs@debian.org> to remain its maintainer or another
volunteer.
> The recent discussions on doing multiarch properly look promising and, even
> better, there seems to be broad consensus that this is the right longer-term
> direction. The question is whether the first round could be ready for squeeze
> so that we don't have to ship ia32-libs again. This obviously depends on
> people wanting (and having time) to work on it; hopefully more will be known
> after the planned BoF at DebConf. Just to make it clear, there are no
> objections at all from ftpmaster to multiarch and we will make sure that any
> archive-side changes which may be necessary will be performed so that we don't
> block it (although looking at the current proposal from Steve Langasek et al,
> we can't really see anything which should need changing).
As per design. :)
There is only one thing that DAK might want to adapt to. For most
multiarch architectures there is a definite main architecture that
most things should be in and then some corner cases where different
architetcure might be prefered or required. Usualy because 32bit mode
has smaller code and is faster than 64bit mode but sometimes the
larger addresss space of 64bit mode is required.
So there might be a need to introduce partial architectures for ppc64,
mips64, mips64el, sparc64 that only carry a small subset of
Debian. The change would be in policy to allow architecture that are
partial and maybe some code to reject unwanted packages from those
architectures.
> This should drop the surprising effects users of the ia32-libs-tools packages
> experienced in the last few days and also allow us to continue supporting users
> of the 32 bit libraries.
I hope most surprises are addresses in the current version, at least
those that aren't as designed. Please do continue to file bugs when
you run into something so it can be addressed in the package and other
people are spared from the surprise in the future.
> This is, as ever, not a statement of the future, but suggestions and thoughts
> on the matter. It has mainly been written due to the fact that we have been
> asked by multiple people to remove ia32-libs-tools but don't want to do so
> until a consensus has been reached on what we're going to do to replace it.
>
> Thanks,
>
> --
> bye, Joerg
> <Md> Sesse: I doubt that many people will switch network
MfG
Goswin
Reply to: