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

Re: multiarch/bi-arch status (ETA) question



On Wed, 6 Jul 2005, Hugo Mills wrote:

  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 doesn't seem to me like something that's wrong.

Are you saying something specific in Debian wouldn't work, and couldn't be elegantly made to work, with the scheme? Reading it, I can't see what that would be - but that's not saying much, that's why I'm asking.

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.

OK... you make whatever changes you expect to make. For the vast majority of packages this is not rocket science. Maybe it's as simple as a change to the ./configure line. You know if they work within the original arch right away. Then when the tools are functional enough you test them in multiarch too. What am I missing?

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?

  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.

  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.

I'm not talking about changes to dpkg, so there is really only one question: can it be done? Or put another way, are lib directories moving? I hear yes. So then I think, do we wait for the chicken to appear before we get the egg? Or can we make a trivial change so that modifying packages (a lengthy process involving mostly lots of identical, trivial changes done by many, many package maintainers) can happen while dpkg work progresses?

I didn't realize this would be controvertial; I just read it in the multiarch document and wondered why it wasn't happening.

Besides, something tells me the dpkg maintainers don't want my (redundant, I think) patch, but Debian could probably use hands fixing the thousands of individual packages...



Reply to: