On Wed, 20 Jan 2010 15:43:40 +0100
Goswin von Brederlow <goswin-v-b@web.de> wrote:
> So you see this is also motivated by getting rid of it faster.
:-)
> I'm talking about a completly new apt-cross-ng, nothing to do with the
> apt-cross mess in Debian currently. And the way it works is that it
> uses the first of the multiarch support in apt to have apt itself
> download the index files for multiple architectures (That removes a
> big mess apt-cross in Debian does) and then adding a little
> post-processing of the index files via the Apt::Update::Post-Invoke
> hook. So I don't work around apt brokenness but I still need a little
> helper to make apt do the right thing on its own. The idea is to be
> minimally invasive.
That sounds like what apt-cross should have been able to do IF we
stopped fooling around with -ARCH-cross package renaming.
As you say, you're using what multiarch support does exist and so your
script appears to be in between apt-cross and full multiarch support.
It is doing things that apt-cross simply cannot do.
That's why naming it apt-cross-ng is so misleading - it should be
apt-multiarch or something that clearly indicates that it relies upon
the nascent multiarch support being developed within apt.
> > We must avoid having -cross packages depending on non-multiarched
> > native packages - even the dummy -cross ones. Arch:all is fine.
>
> 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.
> When the -cross
> package is no longer needed (no reverse depends on it) the package
> will show up in the list of automatic removals (unless set to manual)
> in apt or aptitude.
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.
> Since you do not have suite informations on the dpkg-cross level I
> would stick with the -cross name for a dependency as long as any used
> suite has that package non-multiarch.
How can dpkg-cross know that when it knows nothing about suites? If we
take that as global, it includes old-stable. If we try to pin that to
one installation, deciding which suites are actually used is very
complex. apt-cross simply cannot handle it.
However, the support to help apt-cross is just in the apt-cross package
itself - if we replace apt-cross, we don't have to have suite-specific
lists of multiarched packages.
Current apt-cross will continue to operate *within* any suite which
currently contains it *as long as* builds on that system target Lenny.
The next version of apt-cross will be able to cope with some level of
multiarched packages but there'll come a point where the pain could
become too great and apt-cross would have to deprecated for all except
building to target Lenny.
> Only when all used sites have a
> package as multiarch should the dependency use the multiarch package
> directly. For any chroot with just one suite that would mean it would
> always use the multiarch packages as soon as available, which is what
> you (and me) want. On the other hand for setups with multiple suites
> it would remain on the safe side and rather use -cross when in doubt.
>
> Would that be a acceptable middle ground?
With apt-cross, multiple suites just don't work - it requires a lot of
wrapping to ensure apt-cross is always called with the right --suite
option.
> > What's been missing is how to get apt to do that *after* we've
> > mangled the package names by adding '$arch-cross'. Once we stop
> > doing that, apt is just fine with the dependency resolution in
> > download mode. (See multistrap.) Once we fix that and get dpkg to
> > be able to install the downloaded .debs, apt can take over from
> > apt-cross.
>
> I never had a problem with that in my implementation.
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.
> As said I
> process the Packages file so they exactly reflect the meta
> informations dpkg-cross will create during installation. That way the
> dependency resolution and downloading in apt matches exactly what dpkg
> expects and needs. Apt knows about the libfoo-arm-cross package and
> that it depends on libbar-arm-cross and that it needs to download
> libfoo_1.2-3_arm.deb and libbarm_1.2-3_arm.deb and feet it to
> dpkg-cross. By feeding apt the same meta information as dpkg ends up
> with that proble solves itself.
Your apt scripts and current apt-cross appear to be incompatible.
> It does what apt-cross/dpkg-cross do now but not install a package. It
> would be to just convert a package so it can be put into a repository
> for later use. On the other hand my dpkg wrapper or dpkg-cross
> converts and installs directly.
apt-cross / dpkg-cross can be used just to build without going on to
--install. But I don't think that really matters, the two methods are
not compatible. apt-cross was always a short-sighted package full of
hacks, it was never going to survive large-scale changes.
> Look at it this way: What I add to the existing apt-cross/dpkg-cross
> is that renaming packages to -cross does no longer break things. So
> while packages should still become multiarch ASAP one isn't hampered
> by having -cross packages till that is done.
At which point, apt-cross becomes redundant. Could we investigate
whether apt-cross can be fully replaced (outside use based solely on
Lenny) ?
> Does that explain what I aim to improve better?
Yes.
If apt-cross is replaced, those multiarch files read by dpkg-cross can
remain empty, as you wanted. The helper is part of apt-cross and
doesn't have to be run.
However, the two methods are incompatible. apt-cross cannot do what
your scripts can do and your scripts rely on functionality that is not
in older suites.
Can we get your scripts (under a suitable name) into Debian so that
users and packages can migrate to multiarch?
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.
> > Good! (except that is going to break apt-cross really, really
> > badly.) :-|
>
> *BOOOM* There really is no way around that with multiarch. The current
> names plainly don't allow for multiple architectures.
So let's get apt-cross out of the way and start the work on the
replacement - under a new name, please.
> > It is because apt thinks it is a library. apt-armel-cross doesn't
> > contain apt itself, just the libapt-pkg library.
>
> Sure. I gathered that. But what depends on apt-armel-cross that you
> need it? Is it just so you can cross compile aptitude and synaptic?
There are other reverse dependencies but yes, those are two of them.
Witness the list of binNMU's done after each upload of apt.
> > The list tells you if libbar is multiarched or not. Reliably.
> > dpkg-cross will then use that information when considering the
> > Depends: line of libfoo.
>
> You say suite-specific but when installing libfoo_1.2-3_arm.deb what
> suite does it belong too?
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.
> But lets ignore this for now. If dpkg-cross
> can reliable say when -cross is needed and when not then I'm happy to
> use that same mechanism. Our only disagreement is wether dpkg-cross
> can reliable say so and that we will see when it is used more.
If we can replace apt-cross for everything except Lenny (or older)
with a script that can cope with -cross packages for all, then the
problem goes away. The issue is whether having those local packages
around complicates long, long dependency chains.
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.
When we did have a cross-repository, those upgrade errors still took
place for uncertain reasons, possibly related to how toolchains were
built at the time.
THAT is why I insist on not having -cross packages depending on
non-multiarch packages that are not -cross - apt-cross just cannot
help apt sort out the mess.
> > I'm trying to see a clear dividing line between -cross - OLD, BAD
> > and multiarch - NEW, GOOD! A dividing line that is consistent
> > across package names, script names, paths, behaviour, the lot.
> >
> > It's going to confuse the hell out of me if people keep talking
> > about -cross when talking about the transition away from -cross.
> > -cross must die! (eventually)
>
> This is still all about the OLD, BAD -cross. It will go away with
> multiarch.
Yes, but it depends on parts of multiarch, so it isn't as BAD as
apt-cross.
:-)
> Dpkg will become multiarch aware and -cross packages will be replaced
> one by one with multiarchified packages. The multiarchified packages
> will be instaled identical on arm native or as foreign arch. There
> won't be any ugly moving or deleting of files like dpkg-cross needs to
> do.
I'm getting the hang of that bit now. Re-read the Spec.
> So the multiarch dpkg will never take over the handling of the -cross
> packages but the -cross packages will become obsolete. But as long as
> even one -cross package is still needed dpkg-cross will be needed. At
> least I have not seen any plans to pull the -cross mess into dpkg
> while multiarch tries to avoid the mess alltogether.
dpkg-cross can hang around longer than apt-cross; we might be ready to
replace apt-cross. Your scripts don't appear to need it and do a better
job if the underlying support is available.
> > Any new scripts that will outlast either dpkg-cross or apt-cross
> > should not use the -cross name, whether in packages, scripts,
> > conversions or file paths.
>
> They will not outlast it.
I think the apt multiarch scripts could replace apt-cross, at least
for suites that have multiarch compliant packages.
> > What is /usr/share/apt-cross/package.data about?
>
> It is an executable that can alter the package in any way neccessary
> to make it functional as -cross package.
shell or perl, presumably, being in /usr/share/ ?
> For example the current (non-multiarch) libc6-dev package contains an
> GNU ld script (/usr/lib/libc.so) containing
>
> GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED
> ( /lib/ld-linux-x86-64.so.2 ) )
>
> The libc6-dev-cross package now needs that changed to
>
> GROUP
> ( /lib/x86_64-linux-gnu/libc.so.6 /usr/lib/x86_64-linux-gnu/libc_nonshared.a
> AS_NEEDED ( /lib/ld-linux-x86-64.so.2 ) )
>
> That change would be made in libc6-dev.data and become obsolete when
> eglibc is multiarchified.
> > It is really confusing to talk of apt-cross when you're thinking of
> > a new script and I'm thinking of the current one. apt-multiarch ?
> >
> > apt-cross can only survive as long as the last reverse dependency is
> > not multiarched. It does need to be replaced but I'm not sure we
> > need another version, rather I think we need to fix apt/aptitude.
> > I'm not clear where your replacement fits in.
>
> It just replaces apt-cross until the multiarch transition is
> finished. I expect that to still be a few years so we need a working
> version.
True, but it does seem to be at least one step *beyond* where apt-cross
can take us and therefore, it should be a replacement.
--
Neil Williams
=============
http://www.data-freedom.org/
http://www.linux.codehelp.co.uk/
http://e-mail.is-not-s.ms/
Attachment:
pgpBhWCpfDsUT.pgp
Description: PGP signature