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

Tue Apr 22 20:25:49 UTC 2014

On 22-04-14 06:39, Abou Al Montacir wrote:
>> 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 

Yes. But my point is, why not put the nogui stuff in lcl-units. That
saves us one package which is always needed in conjunction. My point,
why two packages (lcl-units and lcl-nogui) when one is enough. Package
meta-data is shared with ALL Debian users, so we should at least agree
that additional packages are a real benefit.

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

Well, maybe those, but also search for
/usr/lib/lazarus/1.2/components/*{,/*,/*/*}/lib/x86_64-linux/{qt,gtk2}

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

I didn't mean that. What I meant was, wouldn't it just work to put
lcl-nogui in lcl-units and we save one package.

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

Yes, I like the argument. But please also see below. And we shouldn't
exaggerate with the number of packages.

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

Which causes a lot of bugs in Launchpad by the way (for fpc). Please
see: https://bugs.launchpad.net/ubuntu/+source/fpc/+bug/1254262 and it's
duplicates. This behavior is harmful.

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

Yes, but Debian is "complaining" about duplicate files in packages.
Please see e.g. http://packages.qa.debian.org/l/lazarus.html middle
column, or http://dedup.debian.net/compare/lcl-units-1.2/lcl-units-1.2
(This facility is there for a reason).

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

Please don't do this lightly. Can't we just put their widget set parts
in the widget set packages and be done with it. Don't create unnecessary
packages.

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

Well, ask for "uit de verf komen" then.

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

Than this could be easily caught by my automated scripts (needs updating
for lcl-units then). Will do that soon.

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

Ok. I will figure this out.

>> - 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 am not sure you got my point. I understand the reasoning. It is just
that we need to make sure that the right files end up in the right
packages. My point is, how do we prevent errors?

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

Indeed. My proposal, I will create a branch in our git repository and
play around a little bit and show it looks to me we should fix this. If
you like it we can merge that back to the main branch.

Side note: do we agree that I can upload the current status (to have 1.2
in the archive) and fix the rest later? This would mean that Graham can
remove my ugly hack in doublecmd again.

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/20140422/1f659e5d/attachment.sig>