Hallo

> Am 12.10.2019 um 03:56 schrieb Ryan Schmidt <ryandes...@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.

Reply via email to