"Bernhard R. Link" <brl...@debian.org> writes:
> * Ben Hutchings <b...@decadent.org.uk> [120209 20:45]:
>> There is a similar issue with linux-image-*-amd64, which I would
>> definitely like to remove from i386 as soon as possible. We have
>> metapackages to help with this already, but we still need users to add
>> amd64 as a foreign architecture before upgrading.
>
>>From a user's point of view I'd really appreciate if that package could be
> kept. Needing multi-arch enabled (with all the dangers of getting the
> wrong packages installed or the additional index files to download) just
> to have a suiteable kernel would be quite a burden.
>
> Bernhard R. Link
If you are talking just about the kernel then I do agree with you, at
least for wheezy. Then again is there really a good reason to stay with
a pure 32bit userspace if your system is capable of 64bit?
During lasts debconf we had a brain storming session about multiarch and
the archive. One of the things that came up was the idea of (how do I
put this?) "add-on" partial architectures.
What I mean by that is that you do not want to add all of amd64 to a
i386 system or all of i386 to an amd64 system like you said. But you do
want a small subset from it, e.g. the amd64 kernel on i386. Think of
them as a filter over the Packages file. None of them would have a
buildd as they would just be a subset of another arch. With that idea
you would have something like i386-amd64 and amd64-i386 as architectures
that could be added to your sources.list. [Iirc implementation details
where never stated but I think you get the idea.]
So maybe you could think about this and flesh out a proposal and specs
for this.
Note: There was also talk of dropping lilo, grub, isolinux from amd64
and getting them from i386 instead for reasons of not wanting to cross
build 16bit/32bit code on amd64.
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/871uq1e3ls.fsf@frosties.localnet
