Re: multiarch and interpreters/runtimes
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
Reply to: