On Fri, Sep 14, 2012 at 2:54 AM, Daniel Hartwig <mand...@gmail.com> wrote: > On 13 September 2012 23:17, Vincent Lefevre <vinc...@vinc17.net> wrote: >> On 2012-09-11 15:36:15 +0000, Debian Bug Tracking System wrote: >>> [ David Kalnischkies ] >>> * handle packages without a mandatory architecture (debian-policy §5.3) >>> by introducing a pseudo-architecture 'none' so that the small group of >>> users with these packages can get right of them without introducing too >>> much hassle for other users (Closes: #686346) > >> Package 'docbook-mathml' is not installed, so not removed. Did you mean >> 'docbook-mathml:none'? > > This error highlights something: the lack of architecture should not > extend the fullname like that and interfere with locating the package. > ?
If we have no-architecture == native on the commandline and :none isn't
native we have exactly this. It is the usual "problem" in Multi-Arch.
And not only for the commandline, but also for the the library usage itself
as Cache.FindPkg("docbook-mathml"); should NOT return the arch-less
package as it is not what is expected. Expected is that we get the native
architecture, not this useless cra^Wmp architecture (I will get back to that
in just a second).
The idea behind supporting these package at all is that I can write a
request for the release notes to include a
apt-get purge .*:none
and be done with that "architecture".
Doing this with dpkg is a bit harder and as your system is quiet likely in
a broken state we at least have a tool which can recover from that mess.
But yes, I was many times quiet near to just printing an
E: arch-less package detected. Exterminate! Exterminate! EXTERMINATE!
but I can't expect that everyone has watched Doctor Who S02x12 recently,
so the dramatic effect is mostly lost - what is left is that a system which
previously worked and was upgraded by APT ends up in a state which is
so broken that even APT refuses to help fixing it. That is not nice.
> Is there a reason for introducing this pseudo-arch. rather than using
> “I->Pkg.Arch() == 0”?
Yes there is. As I said in my previous mail these arch-less packages are
pretty useless as they form a new architecture, but that is how dpkg wants
it, so be it. This specifically means that the system we are talking about
here is broken before any package is removed as a package with an
architecture can't satisfy a dependency on a package without one
(If we don't accept arch-less packages as native, we can't let them
satisfy dependencies in native - or anywhere else as this means these
packages would be implicitly M-A:foreign).
And that is the problem here: A little optimization went havoc.
APT isn't seeing the unsatisfied dependencies because it doesn't
even create them (see apt-cache showpkg docbook-mathml:none)
because it hasn't seen these none-packages. That's okay if the parent
package is a != none (as we will create it later if we need them),
but for a package == none these dependencies should be created …
=== modified file 'apt-pkg/pkgcachegen.cc'
--- apt-pkg/pkgcachegen.cc 2012-09-09 19:22:54 +0000
+++ apt-pkg/pkgcachegen.cc 2012-09-14 10:16:35 +0000
@@ -922,7 +925,7 @@
// Locate the target package
pkgCache::PkgIterator Pkg = Grp.FindPkg(Arch);
// we don't create 'none' packages and their dependencies if we
can avoid it …
- if (Pkg.end() == true && Arch == "none")
+ if (Pkg.end() == true && Arch == "none" &&
strcmp(Ver.ParentPkg().Arch(), "none") != 0)
return true;
Dynamic<pkgCache::PkgIterator> DynPkg(Pkg);
if (Pkg.end() == true) {
The joy of testing in well-defined self-created environment a "feature"
which is supposed to handle quiet the opposite …
Vincent, could you mail me your status file maybe, so I can run some
real world tests on it?
> $ dpkg -C
dpkg doesn't check dependencies after it has installed packages, so you
will not see broken dependencies with it. Try it with an unpacked
docbook-mathml:none and "dpkg --configure -a" if you don't trust me
(and as usual, you shouldn't) and you will see that dpkg sees the
dependency as not satisfied.
That's why the FullName() for these packages is 'pkg:none' even though
we could easily print just 'pkg' -- it doesn't give a single hint why
a package depending on pkg(:native) isn't satisfiable by pkg(:none).
And we have the problem of needing to tell the user that we remove a
pkg(:none) while installing a pkg(:native) …
(A display issue dpkg completely ignores as you will see)
Attached is a testcase for APT to play with it.
Additional to the one included in 0.9.7.5:
test/integration/test-bug-686346-package-missing-architecture
Best regards
David Kalnischkies
test-fun-with-arch-less-packages
Description: Binary data
