Re: multiarch and interpreters/runtimes
On Sat, Apr 20, 2013 at 05:42:52PM +0300, Uoti Urpala wrote:
> Helmut Grohne wrote:
> > On Sat, Apr 20, 2013 at 04:44:08AM +0300, Uoti Urpala wrote:
> > > 3) P runs a script using system interpreter X, and depends on the
> > > interpreter environment supporting functionality provided by Q.
> > > Q needs to work for the arch matching installed version of X.
> >
> > P (all) +--> X (any)
> > `--> Q (any)
> >
> > The interpreter will most likely be M-A:allowed. So all P has to do here
> > is not add ":any" to its dependencies. Then everything should work out
> > here.
>
> But that 'not add ":any"' is completely impractical. The default system
> interpreter can only have one architecture - what "#!/usr/bin/python3"
> executes. Multiple versions of that can not be coinstallable, and so
> it's completely unreasonable for a foreign package containing Python
> scripts to demand that you change your _default_ Python interpreter to
> another architecture. It would immediately lead to conflicts. In a sane
> system scripts written in pure Python must work with the default system
> interpreter, whatever architecture that is.
You point out a limitation that I'd consider to be a feature. My
proposal requires that every package has a single set of running
architectures that has to apply to all code contained. I did think about
lifting this requirement, but let me first point out how to work around
it. The workaround is not pretty, but doable in all cases.
What you have here is that your script should run in a different
architecture than the rest of the package. You need two sets of running
architectures and that means two packages. You move the script to a
separate Arch:all package with M-A:foreign and depend on it from P.
P (any) ---> P-script (all, M-A:foreign) +--> X (any)
`--> Q (any)
That way P-script will have the same running architecture as the
interpreter, but P can have a different running architecture. (Note that
I am using "running architecture" to refer to the single element of the
running architecture).
> Consider a package that contains a Python script (#!/usr/bin/python)
> doing image manipulation using python-imaging (Depends: python,
> python-imaging) and an i686 binary using embedded Python (Depends:
> libpython2.7, python-levenshtein). As above, installing this package
> must not require changing your default system python to i686. So the
> effective dependencies are: python:any, python-imaging:<whatever python
> is>, libpython2.7:i686, python-levenshtein:i686.
After splitting your package, you have the following graph.
,--> P-script (all, M-A:foreign) +--> python
P (i686) +--> python-2.7:i686 `--> python-imaging
`--> python-levenshtein:i386
So why am I proposing this limitation of a single set of running
architectures per package?
Not to do so would mean to annotate the dependencies with "<whatever
$otherpackage is>". In my opinion this would clutter the dependency
syntax and the field itself. We already have/had problems to find a
syntax for the bootstrap stage annotations. A syntax change is very hard
to implement as it has to touch a large number of tools. In addition I
believe the solution outlined to be expressive enough to cover all cases
albeit introducing intermediate packages. Indeed the cases that have
popped up requiring these additional capabilities are a minority.
Having to split a small number of packages to achieve true multiarch
seems like a good trade off to complicating the dependency syntax to me.
Helmut
Reply to: