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

[Abou Al Montacir]

Hi Ben,
> On Mon, Dec 12, 2016 at 1:08 AM, Abou Al Montacir
> <abou.almontacir at sfr.fr> wrote:
> > Sorry but this is not the way we accept contributions. We have a big
> > responsibility against our users to completely ensure the packages we ship
> > are as safe. as possible This means that we have the duty to inspect all
> > changes coming from new contributers.
> Of course, but verifying that no step of script doesn't touch any
> state outside the current directory is a much smaller burden that
> fully comprehending the whole thing. And you can always run it as an
> unprivileged user, or in a chroot/container/VM.
When dealing with packaging you don't take into account only damage you may
encounter when running the script, but also damage that the script may introduce
in the users system by the mean of the packaged SW.
This means that you will not encounter any issue by running the script, but the
script may modify the source code of the packaged SW so that it performs damage
on end user system after the installation of the generated package.
For more information please refer to http://www.linuxjournal.com/article/7839
> > No sure we need this /etc/fpc/debian.cfg if we remove the alternatives in
> > pre-installation step, but why not. Maybe better call it /etc/fpc/fpc.cfg
> 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.
> Bikeshedding is up to you, but my thought was to imply that the
> filename was not used by upstream fpc.
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.
> > I don't understand why do you need a new package. The fpc configuration file
> > does not belong to any package, it is created on the fly upon installation.
> > Can you please explain more your point?
> 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.
> While it is *possible* to fix this and still use maintainer scripts,
> it is easier (and recommended by that same section of policy) to just
> drop them and ship them as part of a proper package (in conffiles,
> which is implicit for anything under /etc/ (since debhelper v3)).
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.
-- 
Cheers,
Abou Al Montacir

On Tue, 2016-12-13 at 10:48 -0800, Ben Longbons wrote:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20161213/b4866233/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20161213/b4866233/attachment.sig>