On Fri, Dec 9, 2016 at 1:46 PM, Paul Gevers <elb...@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
