<html><head>
    
  </head>
  <body><div>Hi David,</div><div><br></div><div>On Thu, 2023-07-06 at 15:46 +1000, David Bannon wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>There is now a release candidate for Lazarus 3.0 available, of particular packaging interest might be the fact that it now does Qt6 ? Given the current packaging policy of breaking Lazarus up into 'modules' its going to mean an additional module.</p></blockquote><div>Yes we will need to package this and I'm about to do it in next week maybe.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>Is this a good time to consider that packaging policy ? There seems a number of reasons why we might be better having one single Lazarus package instead of several.</p></blockquote><div>I don't think it is good to review our packaging policy, it was discussed long time and fist more the need of a distribution like Debian.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>1. Its the Lazarus Developer's Intention, its how the SourceForge packages are put together. Its how the internal documentation reads.<br></p></blockquote><div>Upstream have their own policy, but be cause they don't have the time to support a split one like us.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>2. Its far less confusing for a new user. As someone who is often involved in helping new comers via the Lazarus Forum and writes some content for the Lazarus Wiki, new users often do not understand why most instructions assume everything is installed. <br></p></blockquote><div>This is why <font face="Courier New, Courier, monospace">aptitude install lazarus</font> will do everything like if it was a single package.</div><div>But more experimented users may decide to install only a subset.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>3. It would make packaging the Debian official packages far easier. Abou does a fantastic job but I am quite sure he does more work, and has to solve more complicated problems because of the dividing he needs to do with the current model.</p></blockquote><div>Not really, the packaging is now quite stable.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>4. A minimal install of Lazarus, based on GTK2 is probably the wrong message to send now anyway. GTK2 is depreciated. </p></blockquote><div>Let me take the example of build systems. One don't want to pull several gigabytes to build a program that only uses <font face="Courier New, Courier, monospace">lcl</font> and <font face="Courier New, Courier, monospace">lazbuild</font>.</div><div>Lazarus IDE is needed only for developers desktop, but all automation, docker images don't need it.</div><div>We should not think only for one side and forget about others.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>The only real reason not to have only an all in one package I can see is diskspace. However, apart from the two Qt modules, Lazarus is of little use without everything so most users end up installing everything anyway, its just they have to make what is often a difficult decision and end up doing so bit by bit. When Lazarus was new, we though a 20G drive was pretty cool. But now, while Lazarus has grown, typical disk sizes have grown far more !</p></blockquote><div>An AWS VM instance has sometimes less than 20GB. Of course you can add more and pay more, but generally you want to pay less if you can do the very same task for less.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>I would not suggest an all in one should pull in the Qt dependencies, that really would be excessive but with the relevant libraries (libqt6pas and libqt6pas) bringing it their own dependencies as needed, the two Lazarus QT 'modules' are not that big anyway !</p></blockquote><div>Again, Qt vs Gtk is not the only thing you need to consider. Fro example, I've recently packaged fp-untits-win to support building Windows applications in a CI/CD flow using Debian. Some of these applications do use lazbuild. So if all packages are to be included in the very same deb, then this deb will double size.</div><div><br></div><div>With current solution, I don't even need the LCL units for amd_x86/i386, only those for win64/win32.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>Anyway, its a suggestion. Please consider. At least the time and effort we get from Abou needs to be valued.</p></blockquote><div>I home I've answered all your concerns.</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex"><p>Davo</p><p>PS : Qt6 looks pretty good. I can build my app (tomboy-ng) with it and, so far, tests fine. There is an issue about theming that shows up in some dialogue boxes being slow to open. Using qt6ct solves this problem, its a workaround but effective. A similar issue exists with Qt5 on some desktops. </p></blockquote><div>PS: I'm currently working, as Lazarus upstream developer responsible of Gtk3 widget set, to bring Gtk3 to the same level of Gtk2. This will allow us to abandon Gtk2 libs dependencies as request in <a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967564">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=967564</a></div><div><span><pre>-- <br></pre><pre>Cheers,
Abou Al Montacir
</pre></span></div></body></html>