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

[Abou Al Montacir]

Hi Ben & All,

On Fri, 2016-12-09 at 20:40 -0800, Ben Longbons wrote:
> On Fri, Dec 9, 2016 at 1:46 PM, Paul Gevers <elbrus at debian.org> wrote:
> > I am trying to understand you shell scrip
> 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.
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. Indeed, a big data damage could result on some bad
change that may appear on some system due to some corner cases. Please don't
understand this as if I'm not saying you have bad intension. I'm just saying
that what Paul is doing is the way any Debian mentors shall proceed according to
the DSC.
...
> > > 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
I agree with you here even if when I implemented that, the include statement was
not present in FPC. That was very long time ago you know!
> 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
This is a better solution indeed
> 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).
Looks good proposal
> 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.
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
> 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
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?
> 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).
That does not make too much sense.
> 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.
I'm not fan of overwriting file.
> 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`).
OK on that
-- 
Cheers,
Abou Al Montacir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20161212/ae8dcfdd/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/20161212/ae8dcfdd/attachment.sig>