On Wed, 20 Jan 2010 18:49:22 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:
(Please don't CC: me, I read the list.)
> >> I don't see why. Since I'm populating the apt database with the
> >> native, the foreign multiarch and the -cross packages the update
> >> process can use either one or any combination of them. So when a
> >> new version of a package comes out the -cross package will be
> >> upgraded just like a native or foreign multiarch package.
> >
> > How are you populating the apt cache? Trying to fool apt into
> > thinking that -cross packages exist in a repository is going to
> > break when dependency chains get long.
>
> But they do exist.
Only in /var/lib/dpkg/status and that isn't enough for apt - at least
it isn't when dealing with long dependency chains with apt-cross.
> Apt-get will download them and tell dpkg to install
> them.
If the package name has changed in that process, the new package name
is unknown to apt.
> The dependency chanins for the -cross packages are at most one
> item longer than the non -cross packages because the only time the
> chain gets longer is when a dummy -cross package depends on a
> multiarch package. If apt can not handle chains one longer than now
> then there is something seriously wrong in apt.
>
> >From experience I can say I never had a problem of apt not being able
> to resolve dependencies with -cross packages for me and I used it to
> install a wine-i386-cross for example (which has quite a big
> dependency chain).
Try GTK+ - it's a far more complex dependency tree; and start from a
clean chroot.
> > With apt-cross and package renaming, this caused horrendous
> > problems in real situations - apt-get simply failed to work or
> > would force the removal of the entire set of -cross packages when
> > any depended on native packages.
>
> Which must be an artifact of the mess the existing apt-cross does. I
> have never seen any apt problem that I didn't get without -cross
> packages also so far.
I don't think you're testing the same kind of problem.
> > If it can really do that with complex dependency chains like
> > installing a full cross-building environment for building GTK+
> > applications in a clean chroot (see #502433) then apt-cross can be
> > replaced.
>
> I believe it can handle that trivially. I will put #502433 down as
> test case.
OK.
> > I think we can keep apt-cross for Lenny and before, demarcate
> > Squeeze/Sid as the painful transition from apt-cross to
> > apt-multiarch and from there on to full multiarch.
>
> Do we need an apt-cross in squeze just to build lenny packages? Can't
> lenny builds done from a lenny base?
There are changes in apt-cross in squeeze that are useful.
> > Whichever suite the Packages files says it is - according to the
> > version. The determination of suite precedes the download stage, so
> > we only get 1.2-3 if 1.2-2 is in a different suite. At least,
> > that's how apt-cross needs to do it.
>
> I ment if you install it with dpkg-cross directly instead of through
> apt-cross. The package might even be locally build and not be in any
> suite.
If you install without configuring dpkg-cross
via /etc/dpkg-cross/multiarch-cross.d/ then you will only get -cross
packages listed in Depends:
> A -cross package can depend on a arch:all package, a binary package
> (arch: native), a multiarch library or a -cross package. And only a
> -cross package can depend on a -cross package.
Having -armel-cross depending on a non-multiarch libfoo just doesn't
work with apt-cross.
> That means that in any dependency graph any non circular path can have
> at most one transition from -cross to non-cross. And only a -cross
> package depending on a multiarch library (libfoo-arm-cross depends on
> libfoo:arm) makes the path longer than without -cross packages. So any
> dependency chain is at most one longer than without -cross. The
> overall graph though can be a tad bit larger. Theoretically the graph
> is at most 3 times larger (every single package native, multiarch
> foreign and -cross) but that will never happen.
>
> Note: Having amd64 + arm + arm -cross packages is still less than
> amd64 + i386 + kfreebsd-amd64 + kfreebsd-i386, wich is a real use case
> of multiarch. So apt has to cope with enlarged dependency graphs in
> the future. Poor us just has to find and fix any bugs that causes.
>
> > e.g. You've got a full GNOME install on amd64. You need to
> > cross-build a GPE package which depends on libgtk+2.0-0 which you
> > also have installed for amd64. If, with apt-cross,
> > libgpewidget1-armel-cross depends on libgtk+2.0-0{amd64} because
> > gtk is not yet multiarched, then trying to upgrade amd64 gtk will
> > cause the removal of lbgpewidget1-armel-cross AND all it's reverse
> > dependencies because they are local packages and not in a
> > repository. Now scale that up to one of the X11 libraries or
> > something like directFB.
>
> Worked for me with having gnome and a 32bit wine installed (which
> needs gtk and a few more). So I'm not worried (yet :) about that. I've
> never seen the kind of problems you describe.
Those problems certainly occured with apt-cross.
> You really just have to try&see. This is a problem one can only
> understand by having an example case that fails (or not :).
So let's get the alternative package into Debian and get testing.
> Should there be support for non script hooks? I would think shell is
> enough with the option of perl if someone really needs to. If non
> script hooks are to be allowed then /usr/lib/... would have to be
> used.
Perl should be allowable - I can't see installations of Crush supporting
multiarch!
> It is hard to find a good name. apt-cross is not enough but
> apt-multiarch promises too much. It isn't real multiarch as it still
> uses -cross packages.
... albeit only in such a way as to ensure the removal of -cross
packages.
> I'm open to suggestions for something inbetween.
It could only be apt-cross if there was a way to migrate from apt-cross
to your script - I can't see that working.
apt-hookma ?
There are already too many packages starting with 'apt-*' - maybe some
other name is going to be better.
I also think that your script would suffer adversely from being named
'apt-cross*' because of the problems within apt-cross.
multiarch-hooks ?
ma-apt ?
maahook ?
It's a transient package, it doesn't need to be a particularly
"attention-grabbing" name, doesn't even have to be that intuitive.
I just think it should downplay the -cross elements which it tries to
replace.
multiapt-tools ?
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpGI6zly2EwE.pgp
Description: PGP signature