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

[Paul Gevers]

On 24-04-14 00:03, Abou Al Montacir wrote:
> On Wed, 2014-04-23 at 22:36 +0200, Paul Gevers wrote:
>> On 23-04-14 22:20, Abou Al Montacir wrote:
>>> Also I was about to split lcl-units into functional group packages. This
>>> is already 34MB.
>>
>> Unpacked I assume? My last version (with qt/gtk removed, was only 8.6MB
>> (xzipped).
> No that was .deb size, built on April 7th.

With a dependency of qt4 on gtk2, the qt4 package file drops from 13MB
to 1.5MB. In total more than half of the size of the lcl files during
the build is currently made up of duplicate files (175 MB of 316MB)

Total size is 331663463 bytes or 316 Mib
<snip>
It seems like you have 3240 files that are not unique
Totally, 176 Mib can be reduced.

(pbuild12311) wollumbin lazarus-1.2+dfsg # ll -h ../lcl-*-1.2*
-rw-r--r-- 1 root root 6.4M Apr 24 05:33
../lcl-gtk2-1.2_1.2+dfsg-1~onlymorellinks_amd64.deb
-rw-r--r-- 1 root root 6.0M Apr 24 05:32
../lcl-nogui-1.2_1.2+dfsg-1~onlymorellinks_amd64.deb
-rw-r--r-- 1 root root 1.6M Apr 24 05:34
../lcl-qt4-1.2_1.2+dfsg-1~onlymorellinks_amd64.deb
-rw-r--r-- 1 root root  12M Apr 24 05:31
../lcl-units-1.2_1.2+dfsg-1~onlymorellinks_amd64.deb
-rw-r--r-- 1 root root 3.4M Apr 24 05:28
../lcl-utils-1.2_1.2+dfsg-1~onlymorellinks_amd64.deb

>> Well, EVERYBODY that uses Debian has the information about all the
>> packages. Each package adds to the information people need to download
>> to be up-to-date. So while you may make it nicer for the users of
>> Lazarus to tweak what they install (do you have any idea how many people
>> are actually doing partial installs) you ADD data for everybody to
>> download. We have millions of users, and only maybe thousand Lazarus users.
> You are talking about the few k bytes of description in Packages.bz2?

Yes, but for everybody, also for people not installing Lazarus. When you
think about this argument, you have to think also about all other source
packages. If everybody was just adding packages without thinking about
it too much, this really does grow. Point is, it is not an issue per se
(you are allowed of course to add packages when needed), but don't think
too lightly of just adding packages.

I have started a discussion on debian-mentors at l.d.o to get some more
opinions on this:
https://lists.debian.org/debian-mentors/2014/04/msg00256.html

> If the solution is to make symbolic links and make lcl-gtk2 depends on
> lcl-qt or the other way, I don't consider this a solution but rather a
> hack. But inside the same package this is of course a proper fix even if
> I prefer to patch the build system and make them generated outside
> qt/gtk2 sub folders. This also will help to reduce compilation time.

I agree with you that there should be no need to have softlinks between
packages if files can be properly distributed, but I do consider
softlinks (be it within or between packages) as a solution for
unnecessary duplication of files (in our case, it does save an awful lot
of disc space). I rather have additional dependencies this than the
duplication.

>>>> 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.
>>> That would work, but I think it is not the right solution, though the easiest.
>>
>> I don't understand what you mean with "not the right solution". Which
>> problem?
> I mean that making lcl-nogui part of lcl-units is the wrong way to go.

Why? You already said that lcl-units will always depend on lcl-nogui. So
what is the additional benefit of have two packages instead of one. But
maybe this part of the discussion has to wait until you have "drawn"
your vision of units packaging.

>> Well, from Debian and Ubuntu point of view they are invalid. The problem
>> is that upstream single *.deb packages make upgrades fail for proper
>> Debian packages. Nothing we can do about it, only upstream can stop
>> shipping single binary packages.
> Yes, this is invalid bug. And the solution you gave is indeed the best
> we can do.

Could you try to ask upstream to stop building these monolithic deb
packages? I believe they are harming the experience of Debian (and
Ubuntu) users in the sense that these users will believe the system
(Debian) is broken. Most people will not notice that this is caused by
external parties that they installed manually (and probably forgot about
that fact as well).

>> Ok, sure. But can you maybe "draw" up some design? You may have a very
>> good point here. But I want to see your bigger picture.
> I'll try to write a wiki page about it with some nice graphs.

I am very curious to see this.

Paul

PS: I am probably going to upload this weekend (unless you object) with
the addition gtk2 -> qt4 dependency as it saves extremely much. I don't
have much trust that fpc will clear the NEW queue particularly soon. And
if it does, I will re-upload to build against the latest.


-------------- 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/20140425/332443a9/attachment.sig>