[Pkg-pascal-devel] Lazarus 1.2.2

[Abou Al Montacir]

On Tue, 2014-04-29 at 08:14 +0200, Paul Gevers wrote:
> 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
Yes indeed, it is more complicated for FPC than for Lazarus, but I still
continue thinking this is a new upstream release and as stated int he
link above it could contain new features.

> > 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.
Please don't do. i don't like to have Debian versions different from
upstream ones. Also I don't expect users to understand this. It looks
like we are trying to workaround going to the NEW queue this way.
However I don't find that FPC and Lazarus stay long time on the NEW
queue. Only 2 or 3 weeks at most. So let's package 1.2.2 and it will be
there in 2 weeks.

> > 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.
Yes indeed, just a rebuild. Of course if there are minor fixes you have
in mind they can go with it.

I think that fpc-abi dependency will prevent migration. However if you
upload today in medium (same justification as for previous upload) then
we are all right.

> > 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?
Because generally a new FPC version comes with new unit format (actually
the compiler version which is stored in the units). This is to make
loading units safe. So FPC will refuse to load units compiled with older
versions unless foced the release mode. And even this may not work if a
real format change was done.

> > 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?
Yes indeed, Lazarus units are compiled with 2.6.2 while the packages
being built are compiled with 2.6.4. Of course if it happens that
lazarus is recompiled before these programs then there will be no issue,
but if it is the other way, then they will ftbfs.

> >> 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.
Ok then if you can do it on 1.2 that could be good

> >> 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.
I think we need to work together on all these things in order to ensure
better solutions and workaround temporary unavailability of each other.

> > 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.
I started some time ago an attempt to fix that, but did not work.
However many changes done by upstream should help now to do it. i think
that we can fix this and I'm sure I can force upstream to take my
changes if they don't break the original behavior.

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/46b97eda/attachment.sig>