[Pkg-pascal-devel] Bug#741792: Bug#741792: doublecmd: FTBFS: install: cannot stat '*.so*': No such file or directory

[Abou Al Montacir]

Hi All,

> Control: severity -1 normal
Great,

> On 07-04-14 08:06, Abou Al Montacir wrote:
> > The decision to mark packages as Manually built was due to the fact that
> > these are considered as provider binaries.
> 
> Clear (an I thought so). Let's call these package library packages.
Pascal units are a kind of libraries. If to be compared with C/C++ .ppu
files are kind of precompiled headers and .o are pure object files.

> > So users need to work with them in their binary format.
> 
> Indeed, but it is our task to make sure it actually works (similar to c
> where you have to state the right "include foo.h" things). I didn't
> update the package yet, as you (Abou) seem to have a much clearer
> picture of fpc and lazarus than I have, that is why I shared my
> observations.
Yes of course, we need to ensure Lazarus is clean and compiling
correctly the projects using it. But it could happen that some
evolutions break backward compatibility.

Here, the main problem I can fond in the logs is:
 ERROR: package not found: /usr/lib/lazarus/default/ideintf/ideintf.lpk

Looking at my laptop I can find:
$find /usr/lib/lazarus/default/ -name ideintf.lpk
/usr/lib/lazarus/default/components/ideintf/ideintf.lpk

So this .lpk file migrated from a location to the other. This is not my
decision but upstream's one.

> > If you remove this, then Lazarus will build them in the user's home
> > directory for each user.
> 
> Ok, let's not do that then, if we can figure out what goes wrong with
> doublecmd
I'll try to build this package, but currently I'm lacking time.

> > There are 2 points here:
> 
> I assume you added the third one later ;)
> 
> > 1) It not relevant to package binary files if you know it will never be
> > used
> 
> Ack
> 
> > 2) On multi-user system this is consuming a huge amount of memory
> > useless.
> 
> Ack (or disk space)
> 
> > 3) It is working only because the source package is installed, while
> > this one is optional.
> 
> Yeh, right.
I can't image that some package build-depends on lazarus-src! Sorry but
this is a complete nonsense. So The option of removing "Manually" is not
one.

> > So I don't agree that we need to remove the manual build flag, and I
> > don't agree that this is a critical bug as LC-QT is a alpha feature.
> 
> Aha, now we are getting somewhere. If this QT thing is Alpha, why
> doesn't our package description say so. That would make things much
> clearer. I didn't know this for one thing, and I am building a qt
> version of my package winff, similar as Graham is doing with his package
> doublecmd.
Do you mean that you will package two versions of WinFF? Does this make
sense? I know I was the first who open this door and packages the IDE
twice, but now I'm realizing I did a big mistake probably.

I really hate that LCL could not build as .so and that could choose that
backend at run time.

> > I'd ask kindly to lower this bug severity or will do it myself in order
> > to avoid a useless removal from testing scheduled for April 14th.
> 
> Done, but it doesn't solve the original problem for doublecmd as a qt
> package was build in the past. So the question remains, how should
> projects (or Debian packages) be handling this in a robust way?
> Apparently depending on the right package is not enough.
I can't answer this one right now, but will probably do this in the next days.

> Paul

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/20140407/c1e5c097/attachment.sig>