On Wed, 18 Oct 2017 at 11:54:49 +0200, Julian Andres Klode wrote:
> On Tue, Oct 17, 2017 at 11:02:21AM -0700, Jonathan Nieder wrote:
> > This is made especially difficult because since policy 4.0.1.0 we are not
> > able
> > to rely on 'priority: optional' packages being installable any more.
>
> Oh did we drop that? Why? So I can build Arch: all packages depending on
> linux-any
> stuff now? The strict installability requirement is much nicer than this one
> (the
> problem is essentially not recursive anymore), and would solve the problem as
> well.
The change in Policy 4.0.1 was to drop the requirement that
Priority: optional packages are non-conflicting. This is orthogonal to
the situation with dbus-user-session, but introduces a new way in which
a package might be uninstallable for a non-obvious reason (previously,
you could assume that Priority >= optional would never be uninstallable
due to conflicts).
Arch: all packages depending on linux-any packages are another case
of packages being uninstallable for reasons that are at least arguably
legitimate. dbus-user-session is an example of this case (its next upload
will be linux-any, duplicating the package 20 times but ensuring that
it only appears on architectures where it would be installable). This
didn't change in Policy 4.0.1.
It's OK for dbus-user-session to make that change because it's tiny, but
if the Architecture: all package was larger, then duplicating it in the
archive up to 20 times for rarer architectures' benefit would probably
be considered undesirable or unacceptable? For example, if packaging
a large pure-Python GUI that wrapped Valgrind, it would be reasonable
to want it to be Architecture: all to avoid duplicating it, but at the
same time it ought to depend on valgrind, making it uninstallable on
architectures to which valgrind has not yet been ported.
smcv