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

[Paul Gevers]

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 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.

>>  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.

> 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.

> 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?

> 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.

> 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).

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.
- 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)
- 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 hope I clarified my concerns.

Paul

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 551 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/attachments/20140421/8d426d1c/attachment.sig>