Re: multiarch/bi-arch status (ETA) question
Hugo Mills <hugo-64@carfax.org.uk> writes:
> On Wed, Jul 06, 2005 at 11:46:12AM -0400, David Wood wrote:
>> On Wed, 6 Jul 2005, Hugo Mills wrote:
>>
>> > They're not (directly) the way that the Debian multiarch is most
>> >likely to go. Unfortunately, the relevant site seems to be down, but
>> >take a look at [1], and possibly some of the other (Google cached)
>> >files in [2].
>>
>> Just out of curiosity; does anyone know what was wrong with the
>> way documented in:
>>
>> http://www.linuxbase.org/futures/ideas/multiarch/
>
> It's pretty vague, since it doesn't deal with any of the problems
> of actually implementing those (fairly high-level) suggestions in any
> given package management system.
That why you read Toleffs proposal for multiarch for debian fo details.
>> On Wed, 6 Jul 2005, Hugo Mills wrote:
>>
>> >>If I may venture a little further, the idea that all of this must be done
>> >>in one giant atomic effort is apparently very popular... why?
>> >
>> > Because you can't demonstrate that your modified packages are
>> >actually going to work properly (and in fact, they won't, if you make
>> >only the modifications you propose) without having a working
>> >multiarch-aware packaging system to test them with.
>>
>> Sure you can. Just test them.
>
> How? You can't install your two multiarch versions of libvorbis
> without a hacked package manager that understands how to do it.
You name packages lib32foo and lib64foo or something non
conflicting. Or you use the multiarch patch for dpkg.
>> It sounds like you want to maintain two sets of packages: one normal, one
>> fixed for multiarch. Is that really easier than just making the links,
>> updating your existing set of packages over time, and doing verification
>> on a pre-release multiarch systems with increasing aggressiveness until a
>> multiarch release?
Over time means something in the order of 3-6 years. And multiarch as
proposed does it without any link farms.
> You make it sound all so simple...
>
> Might I suggest you present a set of patches for dpkg that allows
> the installation of two different architectures of a library in a
> consistent and functional manner? I'm certainly willing to talk over
> the details with you towards that end.
Those should still be on alioth in the biarch tree.
> Yes, I'm harping on about the problems of the package manager side
> of things, but only because those are the ones I've tried to work on
> in the past and know the best.
But someone made the proof of concept patch for dpkg already.
> Hugo.
MfG
Goswin
Reply to: