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

Tue Apr 29 17:57:34 UTC 2014

On Fri, 2014-04-25 at 12:06 +0200, Paul Gevers wrote:
> 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)
This ok for me as a temporary solution. I'll try to find a better
solution as soon as I can afford some free time.

> 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
Thanks for the link. I'll read the thread and comment on it.

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

> >>>> 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.
Yes indeed, it could be a pure conceptual elegance, but we may not care about it

> >> 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).
This is also a little bit my fault. i have write access to upstream svn
and used to be part of the upstream release process. But I no more have
the time to prepare Debian packages in time. So they fall back for this
old way they master. So if we can have a branch for upstream that I sync
in their svn the issue could disappear.

> >> 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.
You need to be patient as I really lack time, but this is promised so
due!

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/20140429/09ff3e0a/attachment.sig>