On Sat, 2011-12-24 at 06:04:46 +0100, Guillem Jover wrote: > If we can agree so far, I'll send my other last part regarding pkgname > input.
So, regarding pkgname input: * The only possible problematic case is related to “M-A: same” packages, as multiple instances can be installed or available. * When using pkgnames as input the cases can be split between, installed and available packages. dpkg mainly deals with installed pkgnames (as for not-installed it deals with filenames), frontends deal with both. * It's always been possible with a non-multiarch enabled dpkg to have foreign arch packages installed, even “M-A: same” ones, although these both require --force-architecture. * pkgname (non arch-qualified) has never meant or referred to a native package when handling installed packages, it has meant the only single possible instance. For available packages it has referred to the frontend's native architecture. * Because both frontend and backend always have knowledge about the installed packages, there's never a reason for the frontend not to arch-qualify pkgnames for the backend when there might be ambiguity (and not doing so brings the problems mentioned previously in the thread), except when dpkg is not multiarch enabled, in which case there cannot be ambiguity anyway (only a single instance that can be installed). * An additional cross-arch problem relates to maintainer scripts doing for example dpkg -L or -l (or other queries) on “M-A: same” packages, because here what's important is either the arch of the package being handled (independent from dpkg native arch) or the arch of the package being queried (also independent from the native arch), so they need to either arch-qualify the package they mean, or pkgname needs to mean all installed instances, anything else will cause problems. In addition the DPKG_MAINTSCRIPT_ARCH envvar cannot be used because it's not related to what's being queried, and --assert-multi-arch might not be fully functional when called from maintainer scripts, so handling the upgrade case if pkgname means native might prove rather tricky as we might not be able to specify neither pkgname:arch nor pkgname:*. The remaning solutions from the thread discussed up to now, taking the above into account are: * Making pkgname mean always the native arch for “M-A: same” packages, but that would make it internally inconsitent (see foreign for single-instance package vs native for multiple-instance package), a backwards incompatible change to its current meaning for installed packages, and would make it possible to make a mess on cross-arch support (cross-grade and different arch between frontend/backend, maint-scripts, etc). * Making pkgname mean all installed instances or configured foreign arches, this is internally consistent and would be backward compatible, it would allow for a smoother upgrade path, but was mentioned in the thread could cause user confusion or to end up with lots of cruft (on the deity list it was mentioned this was the case on rpm-based systems, is there any evidence to back this up?; although as I mentioned the user would be presented the proposed solution first, and could back off), it's also annoying for the user as they need to know beforehand if the package to be installed is “M-A: same”. And a minor one, but for dpkg it's annoying regarding --set-selections as the selection might be unknown from the available db so we don't know if it refers to a wildcard or a single instance. I still see the second solution to be more correct, although it has some rough edges on the user side of the interface, and it can be somewhat cumbersome, so I can see how it's not ideal. But I think there's a third option that might satisfy everyone(?), which is a mix of the above two: * Making pkgname mean all instances for installed packages, and only the native instance for available packages. This makes the semantics fully backward compatible (although internally inconsitent, but that was already the case), it avoids the user ending up with cruft. This would also make for a smoother upgrade, given that dpkg will only handle to be installed packages as filenames and would not make it possible to mess up on cross-arch setups. (pkgname:* for available packages could mean all configured arches, for installed packages it could be an alias to pkgname.) So how about this? Did I miss anything? regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20111228055815.gb24...@gaara.hadrons.org
