[Pkg-pascal-devel] Lazarus 1.2.2

[Paul Gevers]

Hi Abou,

On 29-04-14 06:55, Abou Al Montacir wrote:
>> Just when I was compiling Lazarus 1.2 I noticed that 1.2.2 was released.
>> As fpc 2.6.4 just got accepted, I think it is nice to get 1.2.2 packaged
>> as well. Just to confirm, we agreed to package this with the 1.2 suffix,
>> right?
> No, this is a new upstream release, so it should take its own number 1.2.2.

We had this discussion before [1], and I interpreted your words as, for
fpc patch level is really a new release, for Lazarus, we can consider a
patch level update as a just that, a patch level update. I looked at the
list of changes, but this really looks like a bug-fix release to me. I
rather not want to make new packages just for a bug fix.

[1]
http://lists.alioth.debian.org/pipermail/pkg-pascal-devel/Week-of-Mon-20131007/000060.html

> I think either you re-upload 1.2 and then wait until I finish updating
> 1.2.2

I also started on this, and it is trivial. I was working on getting the
package suffix to be 1.2 but if you really insist we need to get 1.2.2
suffix, we really should re-upload 1.2 to not have to wait on the
package in NEW to pass it. We have no control on that.

> or you accept to have a RC bug.

Just for my understanding, it only needs a rebuild, right? I didn't
notice changes to the Lazarus source with respect to the fpc version. I
hope the "Depends: fpc-abi" will prevent migration of fpc to testing, so
they are forced to go together.

> At least I don't expect FTBFS, but just that users will not be
> allowed to use 2.6.4 as default compiler.

Why is that?

> Of course all other packages like winFF and doublecmd will FTBFS on sid.

Can you briefly explain why that is? Is it because the units are
compiled with a different version that the current compiler?

>> Other issue, that is triggered by Lintian. We currently have a lot of
>> files in /usr/lib that are not arch dependent. According to the
> This we can't easily do anything as it is a upstream choice. I tried in
> the past and the result was quite discouraging.

Ack.

>> Filesystem Hierarchy Standard [1] (which is a must according to Debian
>> Policy 9.1.1) these files must be stored in /usr/share. My understanding
>> is that for Lazarus all the files are (=must be?) in the same tree. A
> Yes indeed, or you patch a lot of code

Ack. And if upstream is not interested, we are not going to do that I
propose.

>> solution could be to put everything that should be in /usr/share in
>> /usr/share and make sym links from the respective /usr/lib location, but
>> that seems like a lot of work. Do we have better ideas? Would upstream
> Maybe I need to dig more inside this issue as I find 100k of symlinks
> not an elegant solution.

Maybe not elegant, but highly effective as long as we can (mostly)
automate it.

>> be interesting in fixing this, or doesn't the freepascal community care
>> for FHS.
> This is more about Lazarus developers than FPC community. The choice was
> made that you can just untar and run. This is to give the impression for
> new users that it is working off the shelf and is just as easy as you
> can imagine. No need to setup paths, to case about anything, it just
> works!

Ack.

> Our work as packagers is to propose solutions that fits FHS but still do
> not break this behavior. I think we need to analyze more deeply the
> situation.

Indeed. Are you willing to spend time on this? I still don't feel
comfortable enough with fpc/lazarus/pascal that I trust my work here. Of
course I can propose things and that you judge.

> Of course the same thing should apply for sources. You can notice that
> contrary to fpc-sources, the lazarus-sources puts files in /usr/lib.

Yes, I noticed this of lazarus-sources. I just consider this one (the
main) of the issues.

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/20140429/28af8c81/attachment.sig>