Lazarus port

[Karl-Michael Schindler]

Hallo

> Am 12.10.2019 um 03:56 schrieb Ryan Schmidt <ryandesign at macports.org>:
> 
> I am not familiar with Lazarus but it sounds like a very strange program indeed if it requires its own files to be modified at runtime. Normally software shouldn't do anything like that.
> 
> Normally in MacPorts we want to ensure that using the `port` command (`port install`, `port upgrade`) is the only way that files get installed into the MacPorts prefix. There are many reasons for this.
> 
> If a user reports a bug, the person who receives the bug report wants to be able to try to reproduce the issue on their own system and know that they have the same software that the user has.
> 
> We want the user to be able to run `port -v installed` and to trust the version number and installation date presented there.
> 
> We want `port uninstall` to completely uninstall a port. If Lazarus recompiles itself and now installs new files that weren't there when MacPorts originally installed it, MacPorts won't know about those new files -- they won't have been recorded in the registry -- so when the port is later uninstalled, those new files would be left behind. That would be bad.
> 
> It's similar to the auto-update capability that many programs (especially GUI programs) have. If such a program is installed via MacPorts, the portfile should ensure that the auto-update feature is disabled so that the user must receive updates only via MacPorts.

I fully support your points and would prefer Lazarus could live up to this. Lazarus also has numerous conflicts with Apple Guidelines due to its Windows heritage in terms of design as well as implementation. However, man power for the macOS port is very limited and the program is huge. I am glad that recently the cocoa based version can finally substitute the carbon one, despite it still lacks some features.

Although I do not see any chance to prevent the recompile, I will ask in the forums/channels/mailing lists. Maybe, there is a way to put everything at least to a var folder or similar. No question, the original building of the .app is a dirty hack, albeit a working one. I’ll take a new initiative to forward my fixes to upstream, at least. 

At the moment, I do not see much, i can actually do regarding this major issue, besides resolving the other minor issues. Maybe, it helps that this is not a one-time activity of me, but will be a long term commitment to MacPorts in the same way as for Fink. Well, hell might freeze over ;-)

Michael.