Hi, On Sun, 2018-08-19 at 08:19 +0200, Paul Gevers wrote: > Hi, > > On 17-08-18 16:54, Paul Gevers wrote: > > > This means that while the packages are versioned, they > > > are not co-installable, rendering the versioning useless. > > > > I hope I reasoned why this is not useless. Co-installability is not our > > worries here. > > I think I wrote this too quickly. co-installability was of course the > reason for the versioned packages (that you suggested to get rid of). > The idea is that upgrades leave behind the old versioned packages (and I > have seen that happening), so you can still compile your programs with > the older versions if you want to. So I don't understand why apt tries > to remove the old packages. Do you know why? Because of course it is > possible that we made some mistake in the dependencies. Or could it be > that this behavior of apt changed sometime in the last years, or that > this behavior depends on an apt option? I do have machines with more than one FPC versions and upgrades are just smooth. Sometimes, old code doe not compile with a new compiler due to soem non backward evolutions, then users may want to keep old compiler until they port their code to the new version.
Also the breaks are only added when a substantial change in packages are made and this happened only a few times. So stating that fpc-$foo-3.0.4 Breaks fpc (<= 3.0.4) is a quick deduction I assume. Can you please check with recent apt and let us know what exact upgrade scenario is failing? -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part