[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: