Portfile magic / xinstall usage / defect?

[Frank Stock]

Thanks for that link Josh.
I did not realize that MacPorts was building an internal mtree.

My main focus is .pkg component installers targeting systems where a development toolchain is not realistic.

* Do you think it would be possible to use mtree and add_users data to generate code for a postinstall script handling user/group creation and file ownership?

* If so, would there be any interest from the MacPorts team in a pull request for that?

-Frank


Since I have the automation, I am able to address 

> On Dec 8, 2023, at 9:17 PM, Joshua Root <jmr at macports.org> wrote:
> 
>> The brotli Portfile:https://github.com/macports/macports-ports/blob/master/archivers/brotli/Portfile
>> Contains:
>>   post-destroot {
>>      xinstall -m 640 {*}[glob ${worksrcpath}/docs/*.1] ${destroot}${prefix}/share/man/man1/
>> …
>>   }
>> 
>> However, after port installation, I look in the work directory and see:
>>   ls -la destroot/opt/local/share/man/man1
>>      -r--r--r--  root  admin  …  brotli.1.gz
>> 
>> Also, /opt/local/share/man/man1/brotli.1.gz contains the same perms and .ext (as the above work/destroot).
>> 
>> * How is the permissions mode 444, instead of 640 (as designated in the post-destroot block)?
>> * And how did it get the .gz extension?
> 
> If you look in the log file for the brotli build after running e.g. 'sudo port destroot brotli', you'll see a line saying "Compressing man pages for brotli". That comes from this code (which runs after all Portfile-defined destroot code): <https://github.com/macports/macports-base/blob/v2.8.1/src/port1.0/portdestroot.tcl#L201>
> 
> - Josh
>