<html><head></head><body bgcolor="#fcfcfc" text="#8b8e8f" link="#4a90d9" vlink="#8b8e8f"><div>Hi Ben & All,</div><div><br></div><div>On Fri, 2016-12-09 at 20:40 -0800, Ben Longbons wrote:</div><blockquote type="cite"><pre>On Fri, Dec 9, 2016 at 1:46 PM, Paul Gevers <<a href="mailto:elbrus@debian.org">elbrus@debian.org</a>> wrote:
<blockquote type="cite">
I am trying to understand you shell scrip</blockquote>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.
</pre></blockquote><div>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.</div><div>...</div><blockquote type="cite"><pre><blockquote type="cite"><blockquote type="cite">
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).
</blockquote>
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.
</blockquote>
Background: managing /etc/fpc.cfg via update-alternatives is
fundamentally wrong, because it is the file read by *all* installed
</pre></blockquote><div>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!</div><blockquote type="cite"><pre>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
</pre></blockquote><div>This is a better solution indeed</div><blockquote type="cite"><pre>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).
</pre></blockquote><div>Looks good proposal</div><blockquote type="cite"><pre>
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.
</pre></blockquote><div>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</div><blockquote type="cite"><pre>
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
</pre></blockquote><div>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.</div><div>Can you please explain more your point?</div><blockquote type="cite"><pre>
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).
</pre></blockquote><div>That does not make too much sense.</div><blockquote type="cite"><pre>
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.
</pre></blockquote><div>I'm not fan of overwriting file.</div><blockquote type="cite"><pre>
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`).
</pre></blockquote><div>OK on that</div><div><span><pre><pre>-- <br></pre>Cheers,
Abou Al Montacir</pre></span></div></body></html>