Re: Dependencies across architectures

[Jens Reyer]

I forgot: the arch specific package needs a Depends on the arch:all
package, which has the wrappers.

Re: Dependencies across architectures

[Jens Reyer]

On 01/07/2018 05:39 PM, Wookey wrote:
> On 2018-01-07 19:23 +0800, Paul Wise wrote:
>> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
>>
>>> If we take Multi-Arch serious, this shouldn't be the case, right?
>>
>> I guess the release team might accept patches to britney for this but
>> I've also a vague memory that they prefer arches to be self-contained.
> 
> This issue affects so few packages that no-one has put in the effort
> to make this (automatic migration with cross-arch dependencies) work.
> I talked about it with respect to doing this for cross-compilers and
> they were OK with doing this properly this so long as there was a good
> reason (but in the end cross-compilers were done a different way so
> there was no need). In the meantime there is a rather hacky whitelist
> for the few packages that do need this (basically wine IIRC).

As *workaround* for this problem you might use some wrapper:

Indeed Wine is closely related to this issue, but we solved the problem
in another way: Wine needs some architecture specific packages which are
only available on either 32-bit or 64-bit.  So our common case on amd64
is that we need to depend on a i386 package.

However we don't use any hard cross-architecture dependencies (any
more?), only "soft" cross-architecture dependencies:  either Depends
with an alternate package from the same architecture, or Recommends.  In
our case:

 wine (arch:all)
 depends:
 wine32 (only 32-bit archs) | wine64 (only 64-bit archs)

We additionally have a wrapper script /usr/bin/wine (in wine) for the
main Wine binary (in wine32).  It gives a warning on console with
instructions how to install the foreign package wine32.  Using
wine64-only is possible, but in most cases wine32 is also wanted.  So
just warning on console, but still trying to run Wine, fits our needs
quite good.


Another affected package is playonlinux.  Its users rely on wine32 even
more then Wine users, so its maintainer would like to depend on wine32
(see: #798780).  For now he chose to just depend on wine, but afaik
plans to add some wrapper with a warning if wine32 is missing.  This
would need to be a graphical one, maybe using zenity.)


I don't know if lowering the dependency to recommends and using a
wrapper script would be a good solution for pyraf.  Assuming "iraf" is
absolutely required to make use of the application, that would mean in
the wrapper you'd need an error message which aborts (and not only warns
as in Wine's case).  Thus one could argue that python3-pyraf is buggy
because it lacks the Depends on iraf.  Counterargument would be that the
wrapper exits cleanly and at least gives _instructions_ how to add a
foreign arch and what to install then.

Greets
jre

Re: Dependencies across architectures

[Wookey]

On 2018-01-07 19:23 +0800, Paul Wise wrote:
> On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:
> 
> > If we take Multi-Arch serious, this shouldn't be the case, right?
> 
> I guess the release team might accept patches to britney for this but
> I've also a vague memory that they prefer arches to be self-contained.

This issue affects so few packages that no-one has put in the effort
to make this (automatic migration with cross-arch dependencies) work.
I talked about it with respect to doing this for cross-compilers and
they were OK with doing this properly this so long as there was a good
reason (but in the end cross-compilers were done a different way so
there was no need). In the meantime there is a rather hacky whitelist
for the few packages that do need this (basically wine IIRC).

So yes there is sort-of an assumption that architectures are
self-contained, but clearly we'd like things to work as well as
possible for the cases where they aren't/can't be.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: PGP signature

Re: Dependencies across architectures

[Paul Wise]

On Sun, Jan 7, 2018 at 5:59 PM, Ole Streicher wrote:

> Unfortunately, this is impossible: the assembler code creates a kind of
> sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
> be simply remodelled in C. In principle, one could re-implement this
> with the libunwind library (see [1]), but since glibc scrambles stack
> information since some time, this does not work anymore.

Ok. I've mentioned it on #debian-ports, perhaps you'll get some help.

> Upstream is difficult for this package: the package has no new upstream
> version since five years and the communication is difficult.

Hmm, that sounds annoying.

> ... therefore I decided to create a temporary fork ...

Watch out, you could end up being the new upstream :)

> If we take Multi-Arch serious, this shouldn't be the case, right?

I guess the release team might accept patches to britney for this but
I've also a vague memory that they prefer arches to be self-contained.

> which is what I pargmatically did now (#886524). I was however not sure
> what the optimal way is, since I also don't know which architectures are
> co-runnable in practice. Theoretically, one could do anything with
> qemu-userland, however.

You can use arch-test to find out which arches a specific system can run.

I guess qemu-user can't run all arches though, like kFreeBSD.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Dependencies across architectures

[Ole Streicher]

Hi Paul,

Paul Wise  writes:
> On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote:
>> "iraf" exists only on selected architectures due to some required
>> assembler code for each arch and problems with big endian.
> There could be a fallback in C for arches with no assembler yet
> and any non-baseline instructions should be detected at runtime.

Unfortunately, this is impossible: the assembler code creates a kind of
sigsetjmp() (with its own calling interface) for Fortran 77. This cannot
be simply remodelled in C. In principle, one could re-implement this
with the libunwind library (see [1]), but since glibc scrambles stack
information since some time, this does not work anymore.

If you have a portable solution, share it with me :-)

> Upstream should fix the code to deal with endianness correctly.
> Please file bugs upstream about these if you didn't already.

Upstream is difficult for this package: the package has no new upstream
version since five years and the communication is difficult. Usually,
this would count as "dead", but the package has quite some importance
for the astronomy community, and therefore I decided to create a
temporary fork, also for other downstreams (Fedora, Conda). The package
has ~750.000 LOC, so all I can do is to keep it working as it is. Big
endian was there at some point (10 years ago) on 32 bit, but they never
had a 64-big big endian release; so unless someone really puts some
efforts in, this will not happen (s390x).

>> From the description of "Multi-Arch: foreign" I would expect that this
>> allows the dependency resolved by using another architecture. However,
>> piuparts (and the migration excuses) claim a missing dependency on the
>> archs not supported by IRAF.
>
> piuparts.d.o only tests amd64 at this stage, could you quote the error
> piuparts gives for you on other arches? I'm guessing you didn't add
> the foreign architecture to the chroot that piuparts was using for
> testing.

It was (probably) my mistake, as I didn't run piuparts locally.

> I'm pretty sure the testing migration doesn't support
> cross-architecture dependencies, but the release team will hint things
> into testing where that is the only thing blocking migration.

If we take Multi-Arch serious, this shouldn't be the case, right?

>> My first thought was to limit the possible archs for python3-pyraf (by
>> explicitly setting the arch list and/or build-depending on iraf), but
>> this would not require the removal of the packages already build.
>
> Looks like you already tried this option, to get it to work you will
> have to ask the ftp-team to remove the obsolete binaries on the arches
> where pyraf no longer builds.
>
> https://qa.debian.org/excuses.php?package=pyraf

which is what I pargmatically did now (#886524). I was however not sure
what the optimal way is, since I also don't know which architectures are
co-runnable in practice. Theoretically, one could do anything with
qemu-userland, however.

Best regards

Ole

[1] https://github.com/olebole/zsvjmp/blob/master/zsvjmp-libunwind.c

Re: Dependencies across architectures

[Paul Wise]

On Sat, Jan 6, 2018 at 5:43 PM, Ole Streicher wrote:

> "iraf" exists only on selected architectures due to some required
> assembler code for each arch and problems with big endian.

There could be a fallback in C for arches with no assembler yet
and any non-baseline instructions should be detected at runtime.
Upstream should fix the code to deal with endianness correctly.
Please file bugs upstream about these if you didn't already.

> From the description of "Multi-Arch: foreign" I would expect that this
> allows the dependency resolved by using another architecture. However,
> piuparts (and the migration excuses) claim a missing dependency on the
> archs not supported by IRAF.

piuparts.d.o only tests amd64 at this stage, could you quote the error
piuparts gives for you on other arches? I'm guessing you didn't add
the foreign architecture to the chroot that piuparts was using for
testing.

I'm pretty sure the testing migration doesn't support
cross-architecture dependencies, but the release team will hint things
into testing where that is the only thing blocking migration.

> My first thought was to limit the possible archs for python3-pyraf (by
> explicitly setting the arch list and/or build-depending on iraf), but
> this would not require the removal of the packages already build.

Looks like you already tried this option, to get it to work you will
have to ask the ftp-team to remove the obsolete binaries on the arches
where pyraf no longer builds.

https://qa.debian.org/excuses.php?package=pyraf

> And, in principle the dependency should work across archs (f.e. for
> x32). But why does it not work with the specification above?

It will work, but only in dpkg/apt.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise