On Wed, 04 Nov 2009 15:11:06 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:
> > 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.
Of course, but 'now' is stuck in a dead end. Please accept that the
dpkg-cross/apt-cross hacks are a complete dead end. Sometimes it is
best to abandon one direction and start afresh. I maintained the
existing hacks and wrote quite a few of my own to get the system to the
point where we could have Emdebian Crush 1.0 - I can honestly say that
I believe there is no "now" for dpkg-cross/apt-cross methods.
If the RFH for apt-cross does not result in any new work, I'm
considering turning it into an RM: before the Squeeze freeze - I'll
almost certainly be turning the RFH into an O: unless someone comes
forth.
> 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.
I'm not sure what is gained by putting more work into a broken system.
apt-cross is dead, if I hadn't nailed it to ftpmaster it'd be pushing
up the daisies already. It's not so much gone to meet it's maker, it's
been given up for dead by it's author!
$ perl -e 'print "parrot\n" if ($apt-cross =~ "/Norwegian blue/");'
$ parrot
(apologies to Mr's Palin & Cleese.)
> 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.
apt-cross cannot support this kind of action, it would need a complete
rewrite. I certainly do not have time to consider any such effort.
> > 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?
502433 is about the inability to accurately use such hacks to get a
clean dependency path from a clean chroot to a full libgtk2.0-dev build
environment using foreign packages.
If you hack around the package names, the careful work of dozens of
maintainers is thrown at /dev/null. It's not surprising that things
break as soon as you try something remotely complicated.
> 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?]
It's been a long time since I got stuck trying to debug that one but
AFAICT I did investigate such ideas but got nowhere. It wasn't that
simple. Patches welcome!
> > 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.
I don't see that there is a "till then". What we have now is broken and
it needs multiarch to fix. If you have patches that can show this
magic, fine, but AFAICT there is no magic available to fix all of the
problems in the current hacks. heimdal is only the most obvious one.
The others relate to the problem of keeping a mixed system upgradable
as well as more that are documented in the debian-embedded mailing
list archive and the EmdebianCodeAudit pages on the Debian Wiki.
> 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.
Patches welcome! apt-cross is already RFH, maybe I should do the same
with dpkg-cross but dpkg-cross is at least able to continue doing what
it can and what it has always done, unlike apt-cross.
> >> 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.
The problem with apt-cross is also time. There is considerably less
developer time available for apt-cross than there is for multiarch.
Right now, I have zero.
What's the saying about developers starting lots of threads and always
having to throw some away?
Things have changed radically for me in the last 6 months, the amount
and kind of work that I am willing to undertake has been drastically
affected. apt-cross is just one of the casualties, but it's defects
were already mortal. It was written as a temporary stopgap but the gap
has outlived the hack. Maybe things will change in 2010.
In effect, the developer of apt-cross has given it up and unless
someone steps up, it will disappear in a blaze of bitrot.
> I never said anything about dpkg-cross working with an finished
> multiarch. Once multiarch is fully reality dpkg-cross is obsolete.
Definitely agreed. ;-)
I would venture that apt-cross is already close to obsolescence. If
anyone thinks differently, please help with the package or request
adoption. I won't hinder anyone who wants to take it over but I cannot
undertake to help development of the current apt-cross codebase.
> 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.
I don't think we can support a transition, that's the problem. The
current method is at an impasse - IMHO there is no route from
apt-cross/dpkg-cross to form a basis from a transition, except
abandoning the hacks and rewriting from scratch. To do that, we need
multiarch to at least be understood by dpkg and apt. By the time
multiarch is in that state, I expect to have the time to do the coding.
IMHO there is no point wasting more time with apt-cross now.
> 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.
We already need a complete rewrite - not sure if that means a 180
degree turn or actually more of an 180 degree turn followed by a path
of uncertain length into the past back to the branch point where we can
get things done TheRightWay.
_____ apt-cross___|
____/
\_____ multiarch
IMHO it's better to just do:
|___ apt-cross___|
____
\_____ multiarch
Granted, I'd like to avoid having to do another about-turn which is why
I think sysroot is the wrong path, but I fail to see a path from
apt-cross into a full multiarch that does not mean completely rewriting
apt-cross and therefore we may as well start the rewrite as soon as
something of multiarch is in place. (Otherwise we end up with TWO
rewrites - actually make that 3 - apt-cross has already been
rewritten once.)
I don't want to get involved in another mire of workaround hacks that
try to compensate for having a broken implementation and a flawed
design. I do not have the time.
Perhaps this list will indicate some of the problems which need to be
overcome to have anything for "now":
http://lists.debian.org/debian-embedded/2009/08/msg00016.html
28 potential bugs (not all in apt-cross but all related to getting
something useful "now" out of the dpkg-cross/apt-cross system), some
could easily be deemed RC, most of the others are at least "important"
severity, most directly flow from the initial design which, in turn,
comes directly out of the hacks that underpin dpkg-cross. *THAT* is why
I believe apt-cross is a dead end. In some ways, it was *designed* as a
dead end. Some of the very earliest commits describe how it was never
expected to have a long future as a package. It was written for a short
term need and it's days have come and gone.
> (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.)
There isn't any point, once dpkg understands that element of multiarch,
dpkg-cross has nothing left to do. Yes, that is the path that
dpkg-cross must take; the path to it's own oblivion. It has always
been that way. The problem is that apt-cross is hardwired to the broken
dpkg-cross methods and would need to be rewritten.
*I do not have the time*. Sorry. (Why is it so hard to give up a lost
cause? Why do others still think there is hope despite evidence to the
contrary?)
There again, this is free software so if anyone fancies doing the work,
go ahead. Don't wait for me to retitle the RFH to an O, if someone here
has the motivation and the time, skip straight to an ITA. It would not
be a hostile adoption, I'd welcome it. Just don't expect me to help
with the rewrite.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/
Attachment:
pgpF52TB5zjMN.pgp
Description: PGP signature