Re: Introduction to multiarch: What maintainers must do
Charles Plessy <plessy@debian.org> writes:
> Le Wed, Jul 29, 2009 at 03:57:31PM +0200, Goswin von Brederlow a écrit :
>>
>> I got some good feedback from my previous Introduction to multiarch
>> post and some good questions. I'm singling out Manoj Srivastava here
>> because he was the most recent to ask this on irc but there where
>> others with the same or simmilar question.
>>
>> The full multiarch proposal can be read on:
>> https://wiki.ubuntu.com/MultiarchSpec
>
> Dear Goswin,
>
> thank you very much for your vulgarisation efforts. Multi-architecture settings
> will be very useful for scientific computing, where we only want the
> applications that really need 64 bits to use this, as there can be a
> performance cost to use 64 bits in cases where 32 would be enough (which means:
> spending taxpayer money to heat the atmosphere).
>
> I have three questions about Multi-arch:
>
> 1) What is the advantage of adding a new field over simply using something like
> â??Arch: multiâ???
Then how you you know what architecture the package actualy is?
> 2) On the Ubuntu page I read: â??It is worth noting that existing package
> management tools will be unable to interpret and satisfy package relationships
> of this format, even when the desired package is available. Consequently, it is
> recommended to defer use of such package relationships in the archive for a
> full release cycle following the package management implementation.â?? Does it
> mean that we need to postpone the implementation of multi-arch in perl packages
> containing compiled code until Squeeze + 2, to keep our promise to support
> upgrades from Lenny?
Depending wether squeeze has support for the new syntax or not, yes,
it would mean that. Unless we can show that it will be possible to
upgarde the package management to squeeze+2 prior to updating perl and
that the new syntax will only make package uninstallable but not cause
parse errors. I don't think requiring people to upgrade dpkg/apt
before upgrading the rest of the system when skipping a release would
be too much of a burden. But it wouldn't be as nice as it could be.
One large question that should be answered first is: Do we desperately
need a multiarch perl? Are there reverse dependencies on perl where
one must be i386 and the other amd64? If it just a "would be nice"
feature then putting it off some might be better than making upgrades
more complex.
> Have a nice day,
MfG
Goswin
Reply to: