On Sun, 2023-12-31 at 10:31 +0100, Helmut Grohne wrote: > On Sun, Dec 31, 2023 at 09:08:31AM +0100, Abou Al Montacir wrote: > > So the new changes triggered more than 2.5k lintian warning. > > https://udd.debian.org/lintian/?packages=lazarus > > Are you referring to those > arch-dependent-file-not-in-arch-specific-directory only? > > > The issue is that Lazarus does not use the same directory structure for > > foreign > > files as expected by MA. > > I'm not sure what you mean with "foreign files". I meant files from other architectures like installing arm64 object files on amd64 machine for cross compilation. > > The lintian tag above complains about architecture-dependent files in > M-A:same packages not being on fully architecture-dependent paths. For > example, usr/lib/lazarus/3.0/units/arm-linux/gtk2/designer.o is > architecture-dependent. Say you would like to co-install > lcl-gtk2-3.0:armel and lcl-gtk2-3.0:armhf, then both would contain this > file, because pascal's structure does not differentiate these. > Attempting to co-install them would result in an unpack error and > release-critical bug. Yes that was exactly what I meant. > > > This may be very hard to change, at least at short term level. > > I agree, but if you want to add M-A:same, you must. Conversely, if you > cannot change this, you must not use M-A:same. Makes sense. > > > Not sure if it is better to override this error for now. > > Definitely not. I said that I was unsure about M-A:same and you should > watch out for the hinter. Hinter results are there: > > lcl-gtk2-3.0 conflicts on 611 files starting with /usr/lib/lazarus/3.0/ on > armel <-> armhf > lcl-nogui-3.0 conflicts on 403 files starting with /usr/lib/lazarus/3.0/ > on armel <-> armhf > lcl-qt5-3.0 conflicts on 236 files starting with /usr/lib/lazarus/3.0/ on > armel <-> armhf > lcl-units-3.0 conflicts on 1234 files starting with /usr/lib/lazarus/3.0/ > on armel <-> armhf > > Adding these up gives roughly 2.5k issues, right? The hinter fully > agrees with lintian. You must not mark these packages M-A:same as is. I agree with you here. > > While removing M-A:same sounds bad, it actually is not as bad as it > seems. The need to coinstall these packages arises rarely. The ability > to perform a foreign installation is the big step. That step is moving > from Arch:all to Arch:any. M-A:same merely is the icing on the cake. > Let's have cake without icing for now. Yes I'll do that. -- Cheers, Abou Al Montacir
signature.asc
Description: This is a digitally signed message part
