Package: synaptic
synaptic is the only[1] blocker before deborphan with multiarch support
can be uploaded. The current synaptic with multiarch support does not
display any package as orphaned if it is used with the upcoming
deborphan release on a multiarch enabled system. The other reverse
dependencies of deborphan work fine with it.
There are basically two sane ways to fix this:
* Pass an option to deborphan to let it print it's output in the way
you like, or teach synaptic to parse both output formats.
* Reimplement the subset of deborphan that you use. An advantage of
this is that this part of synaptic wouldn't require an additional
package to be installed for finding orphans anymore.
Adapt synaptic to work with multiarch enabled deborphan versions:
-----------------------------------------------------------------
I assume that you don't do anything related to deborphan's keep file,
--exclude lists or --show-deps mode; thus I skip explaining how arch
suffixes are handled in these cases.
If the option --show-arch is used, arch suffixes are always printed,
e.g., 'apt:amd64' instead of 'apt'. If the option --no-show-arch is
used, arch suffixes are never printed, that is, it's output is the same
as it is since ten years. If none of these two options is used,
deborphan decides if it prints all packages with arch suffix, or if it
prints all packages without arch suffix. Since deborphan is for
non-relevant reasons not able to ask dpkg if the system has multiarch
enabled, it instead checks if packages from more than one architecture
are installed ('all' is not considered to be an architecture in this
case).
These options are not documented in the man page due to a missing
plausible use case besides usage in deborphan's frontends.
The correct way to check if the above mentioned option --show-arch
(checking for --no-show-arch is equivalent) is available on a system's
deborphan is:
$ deborphan --check-option --show-arch >/dev/null 2>&1
The exit status is 0 if and only if the option is available.
Reimplement a subset of deborphan:
----------------------------------
Reimplementing this subset is way more easy that one would expect.
A naive algorithm with quadratic runtime regarding the number of
installed packages is also possible, but the one below should be faster
and it is still simple. If you already have built a graph of all
package relationships, you could use a simple linear time algorithm.
The algorithm below uses naive set theory and can be implemented using
the standard <algorithm> header:
* Abort if any package is half-installed, half-configured, unpacked,
triggers-awaited or triggers-pending.
* Get a set A of all installed packages that are in section 'libs' or
'oldlibs', but not in base nor marked as $insert_weired_field_names.
* Get a set B of all virtual packages provided by any package in A.
* Create a set C that is a set_union of A and B. A and B are not
needed anymore. (Obviously, if implemented in C++, you wouldn't have
created three sets up to now.)
* Get a set D of all Depends: and all Recommends: (summarized under the
term dependencies from now on) of any installed package, ignoring
versions. To be sure that the final result consists only of packages
that are orphaned, regardless of decisions done by an advanced
solver, alternative dependencies must be parsed as if there would be
a dependency on all alternatives, for example, "foo | bar" must be
considered to be equivalent to "foo, bar".
* Create a set E that is a set_difference of packages in C but not in
D. No package in E has a non-virtual reverse dependency from any
installed package.
* For all packages X in E, check if all virtual packages provided by
package X are also in E. If all provides are in E, then X has no
reverse dependency from any virtual package, and due to above point
no reverse dependency at all. Since X is also in section libs or
oldlibs and not in base (see second point), it would be considered to
be orphaned by deborphan (there are non-relevant historical
exceptions to this).
The above has one bug, packages depending on them self are never
considered to be an orphan, but this happens rarely. Circular
dependencies are not detected too, but they are seldom enough to be
ignored in synaptic, and adapting synaptic's UI for circular
dependencies would be a mess.
Regards
Carsten
[1] The package 'packagesearch' is broken anyway in sid and it is not
part of precise, so I did not manually check it, nor did I read
it's source.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
