Neil Williams <codeh...@debian.org> writes:
> On Tue, 03 Nov 2009 20:22:14 +0100
> Goswin von Brederlow <goswin-...@web.de> wrote:
>
>> Hector Oron <hector.o...@gmail.com> writes:
>>
>> > Hello,
>> >
>> > 2009/11/2 Goswin von Brederlow <goswin-...@web.de>:
>> >> Why do you need --sysroot support? Or what prevents a --sysroot
>> >> of / when using the multiarch directories?
>> >>
>> >> It seems like wasted work with multiarch being a release goal for
>> >> squeeze. Hop on the wagon and make it work for you too.
>
> There is merit in having sysroot for toolchain building and multiarch
> for toolchain usage. sysroot would then be internal to the toolchain
> build.
>
>> > As you already know, multiarch does not have a plan (yet) for -dev
>> > packages. In terms of cross compiling, things are unclear which way
>> > is painless sysroot or multiarch (orthogonal solutions). The more I
>> > think, the more I believe sysroot is painless.
>
> As mentioned off-list, I disagree strongly. sysroot - as it
> appears at the moment - retains the hacks in dpkg-cross which means that
> cross-building anything more complex than a trivial rootfs becomes
> impossible. Cross-building needs to stop requiring package hacks,
> package renaming, version string hacks and the consequent complicated
> changes to the dependency chain.
To be fair that doesn't help NOW. While I agree cross-building should
use the multi-arch directories that will be in preparation of
multi-arch becoming a reality. Until such a time dpkg-cross/apt-cross
still need to do the renaming hacks. But all those hacks are well
understood and existing.
So what I'm suggesting is doing it with hcks now in such a way that
multiarch will remove the remaining hacks when it becomes reality.
>> Your cross-libfoo-dev package would have to solve this.
>
> Changing package names is not acceptable - that is what is causing the
> current logjam. The cross package needs to retain correlation with the
> file in the archive so that the foreign package can be upgraded
> alongside the native arch package and so that the foreign package can
> be installed whilst taking into account the existing Arch:all
> dependencies.
>
> In essence, 'apt-get upgrade' would need to be able to upgrade the
> native arch and the foreign arch at the same time - or at least tell
> the user that the native upgrade also needs a few foreign packages
> upgraded. Otherwise, what happens (now) is that as the foreign package
> (with a changed package name) cannot be correlated with the package from
> which it was built, the built package is therefore removed (with all
> it's foreign reverse dependencies) if there is any kind of transition.
> The removed foreign packages then need to be reinstalled all over again,
> once the native packages have upgraded. Even if the resulting process
> actually does this, it's better to do this in one operation. Merely
> allowing the frontend to realise that the foreign package has been
> updated in the archive, makes it possible.
Well, ia32-apt-get did it just fine and all automatic. There also was
no foreign package with changed name in the archive but the original
foreign package was used. But none the less the converted foreign
package had the right "Source: <source> (version)" information giving
a clear correlation between the converted package and the source it
was build from. Also in any kind of transition the source
transitions. That means both the native and foreign package change
their source and therefore binary version. They are always both
updated and transitioned together. As for forcing both the native and
foreign package to be upgraded by the user as pair that is a simple
Depends. So that really isn't a problem. It is just a matter of
getting the information at the proper place.
The usage is verry simple with ia32-apt-get:
ia32-apt-get update
ia32-apt-get [dist-]upgrade
Or with "ln -s /usr/share/ia32-apt-get/* /usr/local/bin" you can even
save the ia32- prefix. Get your apt-cross to be equaly user friendly.
> The problems are outlined in #502433. The dependency calculations need
> to take account of what is already installed as foreign without native
> versions being considered, yet still take account of Arch:all - AFAICT
> multiarch allows this mode. For it to work, the package actually
> installed has to retain a correlation to what is in the Packages file,
> so that the correct dependency chain can be constructed. Changing
> package names (or even version strings due to strict versioned
> dependencies) in such situations is only going to lead to
> non-installable combinations, as we have now.
ia32-apt-get does this by changing the Packages files post download
and only renaming packages that need to be foreign. There is
absolutely no reason the same renaming can not be applied to Sources
and control files for Build-Depends. That way anything (like apt,
dpkg, sbuild) looking at the Packages, Sources or debian/control files
sees the correct dependency chain and will install exactly the same
packages with the renaming or with multiarch. And a normal
dpkg-checkbuilddeps would also detect missing or wrong packages just
like in the non-cross case.
But what has that got to do with #502433?
That looks to me to be 2 bugs:
1) The libkrb5-dev explicitly mentioned in debian/xcontrol does not
override the heimdal-dev in debian/control.
2) The heimdal-dev-cross package contains a broken library or misses
one. It seems to fall back to the native library, which has the wrong
fileformat. There should be a /usr/arm-linux-gnu/lib/libgssapi_krb5.so.
[Maybe it is looking only in the multiarch directoy:
/usr/lib/arm-linux-gnu/libgssapi_krb5.so?]
> The current behaviour of dpkg-cross interrupting the process of
> downloading, rebuilding,renaming and then installing packages *has*
> to stop. The current dpkg-cross hacks have to be removed and dpkg needs
> to be able to understand how to deal with foreign versions of -dev
> packages in a multiarch setting - then frontends like apt need to be
> able to calculate the dependencies correctly. (This *should* be as
> simple as identifying which packages are foreign then starting the
> dependency calculation from the Packages file for that arch, taking
> account of Arch:all packages that are already installed {as most
> frontends already do}).
With multiarch this will hopefully all go away. But till then you
can't get around some magic somewhere. In ia32-apt-get I only hook
into two places: "apt-get update" and dpkg-deb. "apt-get update" needs
to modify the Packages files post download for the renaming. That
fixes all the Depends. And "dpkg-deb" handles the extraction of
individual deb packages. All the dependency calculations in apt and
dpkg remain 100% as is. For building sources you also need to hook
into the debian/control file but you do that already with the
deban/xcontrol. I agree that the -cross packages should not be handled
magically in a second pass like it seems to be done now. But that is a
implementation detail and not due to the renaming and converting of
packages.
I tried to make ia32-apt-get have as little magic in it as possible
and have it streamlined. That results in a single download and install
process. (ia32-)apt-get install <package> already knows all the native
and foreign packages it will need from the dependencies in Packages.
It downloads them all in one go and passes them along to dpkg. And
dpkg calls dpkg-deb for each one, which converts the debs on the fly
and provides dpkg with the changed names in the DEBIAN/control
file. Dpkg never sees that a foreign package is any different from a
native one.
>> Usualy the
>> cross-libfoo-dev package would only contain the *.so link in
>> /usr/lib/arch-os-libc/ and depend on the normal -dev package.
>
> Forget dpkg-cross, it is a dead package walking. The hacks upon which
> it utterly relies need to be dropped.
The prolem is time. multiarch takes time. After the ubuntu multiarch
announcement the cabal seems to have gone dormant again or back into
their back rooms for secret coding. Who knows when multiarch will be
actually added. Hasn't happened in the last 5 years.
>> For multiarch the problematic part is actually just splitting out the
>> *.so links into an arch:any package and common header files into an
>> arch:all package. A lot of work to modify rules files and lots of new
>> tiny debs for the archive (and NEW processing). So it got put off for
>> later. Your dpkg-cross can automatically do this in 99% of cases
>> leaving verry little handholding.
>
> Please drop ideas of dpkg-cross working with multiarch - what remains
> of dpkg-cross after multiarch will not be anything like what it
> currently achieves. We need a system that can work without mangling
> package names (as this corrupts dependency calculations) and without
> interrupting the normal package installation process. That way,
> 'apt-get -a armel build-dep foo' becomes practical - that's what
> cross-building needs from multiarch.
>
> In particular, we *really must* stop renaming packages when installing
> a foreign version of a -dev package. I might be wrong, but I thought
> that was what multiarch promised - at least if considering a -dev as if
> it was just another package.
I never said anything about dpkg-cross working with an finished
multiarch. Once multiarch is fully reality dpkg-cross is obsolete. The
point was to use the bits and pices of multiarch that are there now
(which is the multiarch directories and toolchain support for them) in
dpkg-cross now. And to use more and more of multiarch as it comes
along and less and less of dpkg-cross. That would mean a smooth
transition.
With sysroot you will be stuck with sysroot until the day multiarch is
100% reality and then you need to do a 180 degree turn and change
everything from sysroot to multiarch. And all that time none of the
cross patches can be merged into debian.
(FYI the renaming is just because dpkg can't handle 2 packages with
the same name but different arch. Once that part of multiarch is in
apt/dpkg the renaming can be changed from foo-cross to foo:arch where
needed. Multiarch adds a feature, dpkg-cross drops one. That is the
way dpkg-cross should take.)
MfG
Goswin
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
