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

[Abou Al Montacir]

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.
> 
> >> meta-data is shared with ALL Debian users, so we should at least agree
> >> that additional packages are a real benefit.
> > I don't understand this, can you please detail more?
> 
> 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?

> > This means that we have still great work to perform in order to reduce
> > the size of packages.
> 
> As I said. I will fix this shortly (just an extension of what I did for
> gtk/nogui).
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 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.

> >> Yes, I like the argument. But please also see below. And we shouldn't
> >> exaggerate with the number of packages.
> > We are not exaggerating, we are trying to handle this in a logical way.
> > I was recently in the need to change the hard drive of my laptop in
> > order to continue using multiple versions of Lazarus. I could afford to
> > do that, but I still think to many users that could not afford that, in
> > many countries of the world.
> 
> Sure, but the argument also goes the other way. Don't create unnecessary
> amount of packages.
There is always a trade off. And the current situation looks like a good
one, we need maybe to polish it a little bit.

> >>> 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.
> > I don't care about launchpad and ubuntu. I only care about Debian BTS.
> > But you are welcome to forward bugs from there to BTS of course.
> 
> 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.

> > Of course, and in my todo list, but did not have time yet.
> 
> No need. I will fix it.
> 
> >> 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.
> > For me a package provides a functionality. I like python-s way to do
> > packages and I'd really like to have something similar.
> 
> 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 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?
> > What kind of errors?
> 
> That we miss files, or that they end up in the wrong package. Please see
> e.g. 02f48b where some files were missed (detected in time, but you
> don't know).
This can happen. Normally we have warnings from dh_install that some
files are not installed. But this does not catch everything. Also it
could happen after a big upstream redesign like what is happening for
upstream packages.

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/20140424/083c11c7/attachment.sig>