On Sun, Apr 21, 2013 at 02:42:32AM +0300, Uoti Urpala wrote: > Should that "set of running architectures" be just "architecture"?
No. Some packages can have multiple "runing architecturs". The most obvious case is M-A:same packages where you can install the same package for multiple architectures. Similarly Arch:all packages can have multiple "running architectures" if all their dependent-upon packages are M-A:foreign or have multiple "running architectures" themselves. > Have you tried to somehow count the affected packages? Where did you get > the "small number" from? There are over 2500 packages with a dependency > relationship on "python" alone that are not named "python-*" (to exclude > python module packages). Is the proportion of those with Python scripts > in addition to other code really that low? I imagined that number. No, I don't have any data and I have to admit that your preliminary data collection hints a problem here. > Would something like apt-file be split into 3 - apt-file, > apt-file-perl-scripts, apt-file-python-scripts? In case of apt-file the split would likely consist of moving rapt-file to its own package and recommending it from apt-file. Still yes, this split would be required by my proposal. On the other hand this split would actually be beneficial. You only have a rapt-file executable if you can actually execute it. I have to agree that this can result in thousands of package slits. Some of the cases you pointed out will just require python without further modules. There you can use python:any. Many of those splits are likely the ones adding optional functionality. Some of them would actually benefit like apt-file would. Still in my opinion splitting thousand packages appears to be less involved than changing the dependency syntax in ways. What I have more doubts about is the actual implementation. There must have been a reason for why this was not built into dpkg right away. A quick check of the source indicates that dpkg really does not check recursive dependencies at the moment. So basically the only way to implement this proposal would be to write virtual and running architectures to the status file. Even then this is not as easy as one might imagine. When installing a M-A:same package suddenly attributes of any number of other packages may change. The nice isolation that currently exists by having discrete states and desired states would be broken somewhat. Possibly we would have to consider reconfiguring packages that change running architectures due to the installation or removal of other packages. Worse, checking the reverse dependencies of a to-be-removed package might simply be impossible to do without a recursive algorithm. Helmut -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421153854.ga11...@alf.mars
