[Pkg-pascal-devel] Bug#845498: /usr/bin/fpc-3.0.0: Provide cross-compilers

[Ben Longbons]

On Fri, Dec 9, 2016 at 1:46 PM, Paul Gevers <elbrus at debian.org> wrote:
> I am trying to understand you shell script

You may find it easier to just run it and inspect the resulting
`.deb`s, then refer to the script only when you want to see where a
specific path/package is handled.

> Just to make sure I am not completely
> misunderstanding, you are trying to use binutils-<gnu-triplet> package
> on the arch of that triplet, right? But e.g. binutils-aarch64-linux-gnu
> doesn't exist on amd64.

Er, yes it does:
https://packages.debian.org/search?keywords=binutils-aarch64-linux-gnu

The *only* packages that are "missing" (actually just outdated and
with wrong headers) are the two x86 arches that are still from
src:cross-binutils rather than src:binutils, for which I filed bug
#846628.

>> Note that the
>> new /etc/fpc/debian.cfg must be installed from the *unversioned*
>> package - which will require a "backwards" dependency
>> (fp-compiler-config-3.0.0 depends on fp-compiler-config-common).
>
> Can you explain where this requirement comes from? If really required,
> then we'll have to figure out an other solution, because circular
> dependencies are a problem.

Background: managing /etc/fpc.cfg via update-alternatives is
fundamentally wrong, because it is the file read by *all* installed
versions of fpc. In order for each FPC to use its *own* fpc.cfg, they
all need to be conditionally included from a *single* fpc.cfg. Since
jessie shipped with packages that manage /etc/fpc.cfg via
update-alternatives, the symlink must still be managed by it for the
stretch upgrade (for the stretch -> buster upgrade this will no longer
be the case).

Fix: Regardless of version, make /etc/fpc.cfg a symlink to
/etc/fpc/debian.cfg file, which then includes the files specific to
the arch and version.

So the hard dependencies will be:

fp-compiler:$a -> fp-compiler-$v:$a
fp-compiler-$v:$a -> fp-compiler-config-$v:all,
fp-compiler-driver-$v(:$a, but Multi-Arch:foreign)
fp-compiler-config-$v:all -> fp-compiler-config-common:all

(Additionally, fp-compiler-driver-$v should have a backwards
Recommends: fp-compiler-$v:$a and a Description to match, so that
people finding it via `apt-file` (including `command-not-found`) will
get the right thing.)

There is no circular dependency - only the -common package has a
versioned -> nonversioned dependency. And the contents will be:

fp-compiler:$a : empty
fp-compiler-$v:$a : executable /usr/lib/fpc/$v/ppc$a
fp-compiler-driver-$v:$a : executable /usr/lib/fpc/$v/fpc, symlink
/usr/bin/fpc-$v and sometimes (via update-alternatives) /usr/bin/fpc
fp-compiler-config-$v:all : /etc/fpc/$v/{mkcfg,local}.cfg
fp-compiler-config-common:all : /etc/fpc/{debian,local}.cfg, *all*
/etc/fpc/$a/{target,local}.cfg and (via update-alternatives)
/etc/fpc.cfg

It would be possible to put the /etc/fpc/$a/{target,local}.cfg files
in yet *another* package, but IMO there's no value in it. (They are
unversioned so that can't go in fp-compiler:$a which might not be
installed if just fp-compiler-$v:$a is).

While it would *currently* be possible to make fp-compiler-config-$v
architecture-specific (since multi-arch allows overwriting files as
long as they are identical), that would prove to be a mistake once
"real" cross-compiler packages are added. By avoiding relying on this,
it becomes easier to transition from *:$a to *-$a packages in future.

All `Architecture: all` packages should be `Multi-Arch: foreign`.
All `Architecture: $a` packages should be `Multi-Arch: same` *except*
`fp-compiler-driver{,-$v}`, `fp-utils{,-$v}`, and `fp-ide{,-$v}` which
should be `Multi-Arch: foreign` since they only make sense on the
host. (The future fp-compiler{,-$v}-$a packages will also be
`Multi-Arch: foreign`).

-Ben