While I don't need to do it myself, I've long thought it might be useful to have the location of etc and var separately configurable. Imagine a bunch of systems that were very similar, but might need individual tweaks; there could be one test system, and another acting as an AFP, CIFS, or NFS server, and sharing with the rest everything EXCEPT etc and var, which should be per-system. Builds would only take place on the (isolated) test system and then packaged up for binary installs on the server system. To the clients, the non per-system directories should be able to be read-only.
The closest one could get now AFAIK is having one's own dedicated build host. That would still mean some work installing individually on systems, and the larger storage requirement for each. No two of mine are presently on the same OS version, and one is a laptop, so I can't do that. But a site with a number of desktops in more or less production use could benefit from such an arrangement. On similar premise, Applications and Library should perhaps also be configurable, presumably to be mounted by clients on /Network/Applications or /Network/Library. On that topic, I see Apple added to the search for at least Applications, in either Yosemite or El Capitan (didn't run my program back when I had Yosemite, so I don't know about that) - the /AppleInternal search is new: 12:00:49[640]lapple:/Users/rlhamil> objpath -h objpath: illegal option -- h usage: objpath [-t type] [-D domain] default type is AllApplications default domain is all Multiple -D options are cumulative. Only the last -t option applies. types: Application DemoApplication DeveloperApplication AdminApplication Library Developer User Documentation Document CoreService AutosavedInformation Desktop Caches ApplicationSupport Downloads InputMethods Movies Music Pictures PrinterDescription SharedPublic PreferencePanes AllApplications AllLibraries domains: all user local network system 12:00:53[641]lapple:/Users/rlhamil> objpath ~/Applications ~/Applications/Utilities ~/Developer/Applications ~/Applications/Demos /Applications /Applications/Utilities /Developer/Applications /Applications/Demos /Network/Applications /Network/Applications/Utilities /Network/Developer/Applications /Network/Applications/Demos /AppleInternal/Applications /AppleInternal/Applications/Utilities /AppleInternal/Developer/Applications /AppleInternal/Applications/Demos > On Oct 6, 2015, at 11:29, René J.V. Bertin <rjvber...@gmail.com> wrote: > > On Tuesday October 06 2015 07:47:03 Bradley Giesbrecht wrote: >>> On Oct 6, 2015, at 3:20 AM, René J.V. Bertin <rjvber...@gmail.com> wrote: > >> We have: >> man porthier > > Thanks, that's a start. I think "hierarchy applied to" leaves it to the > imagination of the reader to what extent ports are allowed to deviate from > that outline or not, though. > > It also suggests that libexec shouldn't be used as a container even for ports > like llvm-xy, and yet there's a lot more in there than just system daemons > and utilities ... > > R. > _______________________________________________ > macports-users mailing list > macports-users@lists.macosforge.org > https://lists.macosforge.org/mailman/listinfo/macports-users >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users
