Re: Bug reports with patches for multiarch support
Guillem Jover <firstname.lastname@example.org> writes:
> There's not yet a multiarch spec, and dpkg does not support multiarch
Both the directory name and the Multi-Arch field has been proposed
unchanged for many years now. With them being added to the toolchain
now they will not change. What do you need for it to be a "spec"?
dpkg does not have to support multiarch for packages to be multiarch
as per design of the multiarch proposal. Packages remain 100%
compatible to even oldstable.
> in any form. We are working on it. The multiarch paths are something
Who is "we" there and would you mind joining
> to be considered pretty stable, but not the new control field. Also
The paths are in the toolchain now. They are stable. Don't even think
of suggesting altering them now.
As for the control field what new ideas do you have that haven't been
discussed to death in the last 4 years.
> some of the patches do not seem right, as they change upstream files
> to use DEB_*_GNU_TYPE directly.
> So, maintainers, please do not apply any of these patches yet, at least
> until we have some form of draft of the spec, or better yet until dpkg
What do you call "some form of draft of the spec" because as far as
I'm concerned that has been done 5 years ago and has not changed since
through all the discussions.
Tell me the format and I will write it up that way for you.
> does actually support multiarch.
You can hold off applying the patches for now but the way to go is to
change packages first. This is a save step along the way.
Then dpkg can be changed in a seperate branch and toroughly tested
before the changes are taken into sid. You need real packages and real
update situations to test all the different new code paths for
multiarch. Without being able to test the dpkg multiarch patches
against the real repository on a reasonably large set of packages bugs
would go unnoticed till it hits unsuspecting users.