[Pkg-pascal-devel] About ptop.cfg and fpc.cfg man pages

Tue Apr 22 04:39:41 UTC 2014

Hi,

On Mon, 2014-04-21 at 17:46 +0200, Paul Gevers wrote:
> Hi,
> 
> Thanks for the detailed response.
> 
> On 21-04-14 17:01, Abou Al Montacir wrote:
> > On Mon, 2014-04-21 at 14:17 +0200, Paul Gevers wrote:
> >> On 21-04-14 11:43, Abou Al Montacir wrote:
> > This should give me a good argument to prepare RCs in the
> > future. 
> 
> Yes, for both fpc and Lazarus, I think we should aim at preparing RCs
> for upload (e.g. to experimental). This also makes sure that we can
> clear the NEW queue early. As long as we make sure that the logic that
> we put into the package version names makes sense, i.e. use the final
> version, not the rc in the name. We did that correct for the latest Lazarus.
I definitely agree here that RC should have the package name suffix with
final release version appended. Indeed the logic behind this naming is
that one can keep during upgrade his old compiler in case new evolutions
cause code breakage. However for RC, it is supposed to be identical to
final release and not stay so long that users can develop specific code.
So it should get discarded by the final release packages and thus need
to have the same package names.

> >> I am not fully satisfied with Lazarus yet, I don't like the qt/gtk
> >> separation as it is. But that is not blocking. I am trying to figure out
> >> how to do it best, but I have one big question to you: how did you
> >> originally decide which files would go where
> >> (lcl-units/lcl-nogui/lcl-gtk/lcl-qt).
> > I did not, the upstream did that.
> 
> I don't understand this remark. The packaging is done by us. In the
> current logic, it is decided in d/lcl-*.install.in which files package
> go where. AFAIU, there is no smart detection to follow upstreams choices.
Let me be more clear here. Yes we decide which files, or precisely which
directories, go into each package, but the location of these files is
not our decision. For example we decided to put
components/synedit/design/units/*/gtk2 into lcl-gtk, but never that
synedit untis do into 
components/synedit/design/units/*/{gtk2,qt,...}. This is an upstream
decision. I assume because synedit is so complex component that it needs
ifdefs in its code.

> >>  If you are confident that all the
> >> qt/gtk files in lcl-units should be mere copies (and thus fixable with
> >> softlinks) I am fine with the proper separation, but if there actually
> >> should be a lot more files in lcl-gtk and lcl-qt from lcl-units, we need
> > For me we should diff files and produce soft links if they are the same.
> > There is probably something that does this automatically.
> 
> Yes, there is. I already implemented this for lcl-nogui/lcl-gtk
> de-duplication. At the expense of a dependency of lcl-gtk on lcl-nogui.
This is not so bad, because you need lcl-nogui to be installed anyway
otherwise Lazarus will complain. So it is fine for me that both lcl-gtk
and lcl-qt depend on lcl-nogui 

> > lcl-units contains the code that is widgetset independent by design such
> > as components which do not have ifdef in their code.
> 
> Well, is supposed to, I guess. There are multiple units in lcl-units
> which have a gtk and a qt directory in their tree.
Can you give examples? I see only:
$ls -d /usr/lib/lazarus/1.2/components/*/units/i386-linux/{qt,gtk2}
/usr/lib/lazarus/1.2/components/ideintf/units/i386-linux/gtk2  /usr/lib/lazarus/1.2/components/synedit/units/i386-linux/qt
/usr/lib/lazarus/1.2/components/ideintf/units/i386-linux/qt    /usr/lib/lazarus/1.2/components/turbopower_ipro/units/i386-linux/gtk2
/usr/lib/lazarus/1.2/components/synedit/units/i386-linux/gtk2  /usr/lib/lazarus/1.2/components/turbopower_ipro/units/i386-linux/qt

> > The lcl-nogui contains components that are not graphical and thus are
> > independent from widgetset but also do not link to any widgetset.
> 
> Sure, I understand the reasoning, but lcl-units depends on
> lcl-gtk|lcl-qt, so you will install either gtk or qt anyways. What is
> the added value of a nogui package? Only when you want to do nogui stuff
> and install qt?
This is a kind of dependency (maybe bad) optimization. Because both
lcl-gtk and lcl-qt are supposed to depend on lcl-nogui. Anyway you can
not ensure that lcl-units are working fine without having either of
widget set packages installed. Sure you can compile non graphical
applications, but this is not enough. For me the dependencies should
ensure you can link any gtk/qt application once lcl-gtk/qt is installed
otherwise our users will complain.

> > lcl-gtk and lcl-qt are meant to contain the widgetset dependent units.
> > These are either interfacing units or components with native
> > implementations like some native buttons, memos and text entries.
> 
> Sure, but if we can't get the packaging right (i.e. that these packages
> really only contain unique files) the advantage of having separate
> packages is lost. I think multiple packages are only warranted if we can
> make sure that there is a good use case to install one package and not
> another one, and that this also works dependency wise. Currently I am
> not so sure of that.
The purpose I first introduced this split was to allow users with low
disk space, including embedded systems like arm boxes, to install only
what they need. It was really hard to convince upstream about this, and
you can still see that they continue to distribute a unique debian file
or put all debs in one tar.
The fact that lcl-qt and lcl-gtk have duplicate files is not really a
problem, because most users don't install both. You either install gtk
or qt. Of course a few users will want to install both, but those I
assume have big hard drives and will not complain about the duplication.
Now, that said, I think that lcl-qt should also depend on lcl-nogui.

BTW, It could also be a solution that synedit and turbopower-ipro get
their own packages that have both widget set variants optionally.

> > I hope this is clear now.
> 
> Well, you explained the intention, but that was already clear. My point
> is that I don't think the current *packaging* implementation "comes out
> of the paint" (as the Dutch say).
I'm working in Leuven since beginning of the year, but still don't know
this one ;) I'll ask!

> To summarize my current concerns:
> - lcl-units-## contains directories that have gtk/qt in them. I haven't
> 100% verified that the files in those directories are bit-by-bit
> identical, but if they are not, they should go to the gtk/qt packages.
Yes; I already did that for synedit, but this is no exception.

> - lcl-units-## depends on lcl-gtk-## OR lcl-qt-##. Currently lcl-gtk
> depends on nogui to reduce lots of disk space, so lcl-nogui-## does not
> really warrant it's own package (except if you rather have qt and nogui)
both lcl-qt and lcl-gtk should depend on lcl-nogui. Also you should find
the same file duplication in lcl-qt.

> - there is no logic in our packaging about which files go where. It is
> hard coded, making mistakes very easy to make. I think we should be able
> to come up with logic. But that probably means we have to fix the
> upstream code to build current widget set dependent stuff that is really
> widget set independent in a independent directory.
I don't agree here. I've already explained the logic behind packaging
for David and the translation team when they did the review of packages
description. I can recall it, but this means that the current packages
description is not complete and we should make it clear for the user by
the mean of the packages description.

> I hope I clarified my concerns.
Some are clear and some still need to be discussed. But this is the main
goal of this mailing list: reach agreements and make arguments available
for others so they can agree or challenge.

Cheers,
Abou Al Montacir,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140422/eb3b5ec5/attachment-0001.sig>