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

Paul Gevers elbrus at debian.org
Wed Apr 23 20:36:16 UTC 2014


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

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

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

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

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

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

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

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/20140423/8c84016d/attachment.sig>


More information about the Pkg-pascal-devel mailing list