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