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

[Ben Longbons]

On Tue, Dec 13, 2016 at 2:14 PM, Abou Al Montacir
<abou.almontacir at sfr.fr> wrote:
> Hi Ben,
>> The reason is that previous fp-compiler-$v packages might be manually
>> installed, and thus stick around after the unversioned fp-compiler
>> package changes its dependency to the newer fp-compiler-$v.
>
> This may be solved with a conflict or/and break statement I assume.
> We can always claim that users should choose between old compiler versions
> and multi-arch support.

That's possible I suppose. Note that we aren't doing any changes that
fundamentally couldn't be applied to older versions if people want to
make their own.

> We try no to diverge too much from upstream and we try to make our patches
> integrated upstream. So I'd prefer to use the same file and make this
> integrated somehow if possible. I admit I have no clue about any other Linux
> distribution. The last non Debian system I used was 10 years ago.

Multi-Arch support at *all* is a divergence from upstream. AFAIK, the
only other distro that offers *any* multiarch support is Gentoo, and
it is nowhere near the quality of Debian's. Possibly NixOS can do it
too, but it fundamentally can't use upstream's configuration, so it
can be ignored.

>> The way it is currently done violates Debian policy 10.7.3 [1], which
>> requires that administrator changes be preserved during upgrades.
>> Currently, fp-mkcfg-$v overwrites the file during every postinst.
>
> I don't agree here. The file is not overridden, as the real file is
> versioned. The link is an alternative selection so it is not a regular file.
> The change results only from the link update. If the system administrator
> decides to use manual selection of a given version, then his choice is
> preserved.

/etc/fpc-3.0.0.cfg counts as a configuration file too - what if the
administrator really wants to make changes specific to version 3.0.0?
If the administrator edits it, those changes will be removed when
upgrading from 3.0.0+dfsg-9 to 3.0.0+dfsg-10. Thus, policy violation.

Plus, it is *way* simpler to avoid maintainer scripts.

> I may agree here, but I think we should avoid adding a new package. We
> should first try to use an already available package, if we fail to find a
> solution then maybe we can add a new one.

There are two requirements for whatever package ships the config file:
* It must be `Architecture: all`.
* It must be unversioned, but allow dependencies from versioned packages.

There is no package that currently meets those requirements other than
fp-docs and fpc-source.

We will need to add many new packages *anyway* for "true"
cross-compiler support. There's a *very* good reason that dozens of
gcc-$arch and libc6-$arch-cross packages exist. If nothing else, think
about e.g. the cross-compilers that target Windows or AVR, which can't
be done by multiarch.

-Ben