Paul Gevers wrote:
On 07-11-14 23:48, peter green wrote:
One thing that is almost certainly a factor is that wheezy's freepascal
can't remain installed on jessie, not because of anything to do with
jessie's freepascal package but because wheezy's freepascal package
conflicts with jessie's binutils.
Can you elaborate a little more, as I am sure I don't fully understand
you. conflicts, as in debian/control? I don't think that is what you
mean, so somewhere there is information lacking in the dependency
resolving chain, no?
Wheezy's freepascal (specifically fp-compiler-2.6.0) conflicts with
binutils-gold. jessie's binutils provides binutils-gold hence wheezy's
freepascal cannot remain installed while upgrading to jessie's binutils.
It may be that a stable update to
allow wheezy's freepascal to coexist with jessie's binutils is a good
idea (the fix is not massively intrusive and i've already backported it
for users of the raspberry pi foundation raspbian wheezy image which
ships an updated binutils).
So what change in binutils is needed? What exactly is the problem? Have
you already contacted the release manager(s)? Is this about the gold linker?
It would be a stable update to freepascal not a stable update to
binutils. I have not contacted the release team at this point, I was
waiting to see if other people involved in freepascal packaging thought
it would be a good idea first.
Freepascal doesn't work with the gold linker and there doesn't seem to
be any interest from suitablly skilled people in fixing this. In wheezy
the binutils package symlinks ld to ld.bfd but there is a package called
binutils-gold which changed the ld symlink to point ad ld.gold.
Accordingly in response to a bugreport complaining about freepascal not
working that turned out to be caused by the system having binutils-gold
installed we added a conflicts on binutils-gold.
Post wheezy the binutils packaging was changed, the binutils-gold binary
package was dropped, a binutils-gold provides was added to binutils and
maintainers were told that if they required a specific linker they
should invoke it explicitly (and gave C specific instructions for doing
that). The symlink was left pointing to bfd but there was an implication
that it might be changed to point to gold in the future. This action
rendered freepascal uninstallable in sid.
To fix this I removed the conflicts and modified freepascal (small patch
to the upstream code, which was somewhat fun to write due to dubious
assumptions regarding dots in filenames in the upstream code) to call
ld.bfd explicitly. That was included in the 2.6.2-3 upload (which had to
be built manually for each architecture which was a PITA and also had to
be reboostrapped in ubuntu which was even more of a pain because hardly
anyone has binary upload rights in ubuntu). I did not at the time see
any reason to push this change back to stable.
Some time later the raspberry pi foundation started shipping an updated
binutils with the aforementioned as part of their raspbian images. As a
result of this I split this change out, applied it on top of the
raspbian wheezy 2.6.0 package (which is nearly identical to the debian
2.6.0 package, just with changes to the minimum cpu requirements for
armhf) and placed it in a repository so people using the raspberry pi
foundation raspbian image could continue to use freepascal. A debdiff
can be found at http://plugwash.raspbian.org/fpc_2.6.0-9+rpi1+wsf1.debdiff
And then this bug turned up.
As a side note, I recently uploaded fpc 2.4.6 to wheezy-backports, I
assume the breakage is not the other way around, right?
Yep jessie's freepascal packaging should be fine with wheezy's bintuils.
Holger Levsen wrote:
One thing that is almost certainly a factor is that wheezy's freepascal
can't remain installed on jessie, not because of anything to do with
jessie's freepascal package but because wheezy's freepascal package
conflicts with jessie's binutils.
I dont understand this. why should wheezy's freepascal stay on a jessie system
if there is a new version in jessie?
The freepascal packaging is setup so multiple upstream versions can
coexist on a system, i'm not entirely convinced the complexity this adds
is needed but it's how the packaging has been done for quite some time.
Normally during an upgrade the old upstream version would be kept unless
it was removed by the user or by autoremove. However in the case of
wheezy -> jessie that is not possible due to the issue I detailed above
and the depsolver must remove wheezy's freepascal packages to allow an
upgrade to jessie's version of binutils. If the underlying issue was
that the depsolver wasn't trying hard enough then making it's life
easier by making a stable update to wheezy such that wheezy's freepascal
remained installable in jessie may have been a sensible idea.
Maybe important would have been a better choice, I don't think a rc bug
would be helpful, the jessie packages are still usable, it's just apt
may need a helping hand to upgrade things correctly in some cases.
fails to upgrade is an RC bug.
If I was presented with reasonable evidence that there was a bug in
jessie's freepascal packaging preventing upgrades that would be one thing.
However that is not what I was presented with, I was presented with the
output of a test script that was too crappy to even show what commands
it was running trying to test an upgrade of a metapackage. It was
faililng to do so and dumped some information on it's failed attempt at
upgrading. Significiantly i've learnt the hard way that the output apt
dumps in this scenario has little to do with the real problem. In
particular it doesn't say anything about why a package "is not going to
be installed" (which for a package installed at the start really means
it wasn't to remove the package), no information about what version of
the package has the unsatisfied dependency and no information about why
a package is not being upgraded.
Afaict if either apt-get upgrade or apt-get dist-upgrade is producing
output like that then either the system had broken dependencies before
apt was run or something is seriously wrong with apt. If apt can't find
a path to upgrade something it should just not be upgrading it.
I therefore assumed that the script was trying to upgrade the
metapackage using "apt-get install <packagename>" which afaict is much
harder on the depsolver than using dist-upgrade and afaict is not
gauranteed to work without adding additional stuff to the command line
to push the resolver in the right direction. As such I downgraded the
bug. It seems that the assumption was wrong
If you want a more positive maintainer response to bugs then please fix
your test scripts to print the commands they are running rather than
leaving us to make wild guesses at what the failing command actually
was. Please also try to do some basic triage rather than pointing the
finger at whatever package name apt barfs out.
And then, after writing the above, I remembered to check whether jenkins
could reproduce the issue and it could not, thus closing the bug.
https://jenkins.debian.net/view/edu_devel/job/chroot-installation_wheezy_install_education-development_upgrade_to_jessie/2/consoleFull
The log nicely shows how the fpc packages are first kept back at
"apt-get update" and then afterwards are upgraded nicely with
"apt-get dist-upgrade".
A possible reason could be that #1 used dpkg_1.17.13 while #2 used
dpkg_1.17.21 though this is really just finger pointing in the sky ;-)
I'm glad the issue has been resolved howsoever and that jenkins detected both
the problem as well as the fixing correctly.
Probablly not worth trying to debug further unless the problem resurfaces.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
