Re: -= PROPOSAL =- Release sarge with amd64
Raul Miller <moth@debian.org> writes:
> On Sat, Jul 17, 2004 at 07:00:58AM +0200, Goswin von Brederlow wrote:
>> > Is this purely because of linking problems with shared libraries, or is
>> > there some other kind of need to support two diferent instances of the
>> > same application?
>>
>> Its a problem with avoiding archive bloat through biarch capabilities
>> in dpkg. You end up with multiple /usr/share/doc/package/copyright files.
>
> You seem to be answering a question I'm not asking.
Sorry, yes.
Supporting two packages with the same name but different arch is for
shared libraries and their -dev files. Changing the name, esspecially
the -dev files, would mean changing the (Build-)Depends/Conflicts. To
avoid that having multiple packages with equal name is considered
required.
If you just want a rudimentary 32/64bit support renaming is an option
but then you are back to the "ia32-libs" approach.
>> Again, see past discussions.
>
> Which ones, specifically?
About the biarch proposal. Hunt the debian-amd64 ML archive.
>> > Can you tell me why you think "mixing 32bit and 64bit" isn't a solvable
>> > problem?
>>
>> Because you won't get upstream to accpet patches and the same probably
>> goes for the Debian maintainers for binutils and gcc.
>
> In other words, you'd have to fork those packages until the issues
> got resolved?
If you must.
>> You will always get the warnings there which I feel is unacceptable
>> since its avoidable.
>
> Then leave that as a known bug until multiarch is ready. Doesn't sound
> like a showstopper for biarch.
>
> Or, if it is too annoying to tolerate, then it's worth addressing.
>
>> > For example, I can do without "multiple instances of the same package
>> > under the same name for different architectures" -- for the few important
>> > packages I have to have side by side, giving them new names and manually
>> > sticking them somewhere else is not that big a problem. You've already
>> > been doing this for IA32.
>>
>> That is what ia32-libs is doing. But its only ment to support thrid
>> party binaries and not for ia32 debian packages.
>
> That's half the issue.
>
>> >> >> Have you made a biarch package yet? If not, please do that and come
>> >> >> back when you have. It's painful, to do it the right way.
>> >> >
>> >> > What do you mean by "the right way"? And, why is that way right?
>> >>
>> >> In a way that has a minimum impact on the tools and sources. The les
>> >> that needs to be changed and the simpler the change the better.
>> >>
>> >> Like asking dpkg where libs should end up and using that as a variable
>> >> instead of just replacing lib/ with foobar/ (as an example).
>> >
>> > Why does this need to be in dpkg? For contrast, what's wrong with some
>> > table represented in some file in /etc/?
>>
>> 'dpkg-buildpackage -aamd64' and 'dpkg-buildpackage -ai386'. Remember,
>> you are aiming for multiarch support so the right arch/path is nothing
>> fixed.
>
> Let me ask that question a different way: what's the sequence of events
> leading up to the point where dpkg-buildpackage -a works?
You can go too ways. Build a biarch capable toolchain or build two
seperate toolchains that are multarch capable. Since we have a biarch
toolchain you might want to start there.
The next step is to get the dpkg-dev tools to change their output and
behaviour according to the -a option used in dpkg-buildpackage.
Currently the -a option has only a very limited effect. But maybe
-a<arch> is not the right way to build packages, there a different
ways.
An alternative to the -a option would be using "linux32", which turns
the i686 uname emulation on. Linux64 reverts that. dpkg-buildpackage,
dpkg-deb, dpkg-gencontrol, ... should probably be made aware of the
uname and change their output accordingly.
That would be easier to achive since the -a option would have to be
passed through debian/rules to any dpkg-architecture or dpkg
--print-architecture calls somehow. The uname emulation is passed on
to children automatically.
So now we have a toolchain able to produce 32 bit and 64 bit binaries
and a way to tell packages to build for 32bit or 64bit.
Was that what you asked?
The current state of multiarch can probably be described as
deciding, testing and implementing how this is going to work exactly,
what tools to modify in what ways to best achive multiarch
capabilities.
We know how we want the debs to look like at the end but very little
on how to get them there has been finalized yet.
> Or do you expect that -a has to work before any other multiarch work can
> be done?
You don't need to be able to build packages for multiple architectures
to work on multiarch. As said before multiarch will change all archs
to a straight forward unique lib path (${prefix}/lib/`gcc -dumpmachine/).
Nothing prevents you from porting packages to multiarch on m68k for
example.
The first packages that need to be ported are glibc, binutils and gcc.
>> > I personally can probably live with LSB compatability for 32 bit,
>> > instead of LSB compliance. Maybe.
>>
>> Do you need to build libraries under debian to be used on a non debian
>> amd64 LSB compatible system?
>>
>> Because that is the only thing breaking (the deb file contains the lib
>> in the wrong dir) we know of.
>
> Me personally? No, I don't need that.
>
> But that's not the only thing breaking.
>
> For example, upgrade from i386 is broken. Which is sad.
Its not intended to work before multiarch. And multiarch is not going
to get much attention before sarge is out of the way.
MfG
Goswin
PS: If you are truly intrested in developing ideas for this I suggest
moving to debian-amd64. That list is more on topic for it.
Reply to: