Hey there<br><br>that's a long time since I've been away from the ML (though still acting a bit in the shadow)!<br>I'll still be away from the ML, and NUT in general due to personal / professional constraints.<br>
thus answers awaiting from me will be lagging a bit more...<br>I'm doing my best to find a solution.<br><br>anyway, I've a bit of time, energy and interest to reply to the present one<br><br><div class="gmail_quote">
2013/3/11 Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com" target="_blank">clepple@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Mar 11, 2013, at 5:07 AM, <VaclavKrpec@Eaton.com> wrote:<br>
<br>
> Do you by any chance have a list of package names<br>
> for the OS X (mine is just a fresh clean installation)?<br>
<br>
For a basic build test, you can install the Xcode command line tools from the Apple developer site or the App store. The base OS seems to have all of the headers and libraries needed for OpenSSL and NetSNMP.<br>
<br>
For USB, NEON and other libraries, you need Fink or MacPorts. I prefer Fink, since it uses the familiar dpkg under the hood, but MacPorts is a little more flexible in other areas, since it has a Gentoo-like variants system. Along these lines, Fink strives to have every built .deb package be the same (variants are implemented by building and installing differently-named .deb files), whereas MacPorts allows the packages to be different depending on which options were selected. Fink also keeps out of /usr/local, since many ported Mac applications drop old versions of libraries there.<br>

<br>
You can have both installed at once, but it is only recommended to have one active in $PATH when building.<br>
<br>
Fink: <a href="http://www.finkproject.org/" target="_blank">http://www.finkproject.org/</a> or <a href="http://sf.net/projects/fink" target="_blank">http://sf.net/projects/fink</a><br>
<br>
MacPorts: <a href="http://www.macports.org/" target="_blank">http://www.macports.org/</a><br>
<br>
> I'd also appreciate an advice on the packages source and<br>
> an overview of OS X packaging system (I suppose it has some<br>
> but I've never worked with it, before).<br>
<br></blockquote><div><br>maybe a good time to integrate Mac packaging files into the tree?!<br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Aside from Fink and MacPorts, we haven't focused on the OS X Installer.app system since we don't have any GUI applications,</blockquote><div><br>work started by Emilien with Hazelnut:<br><a href="https://github.com/balooloo/hazelnut">https://github.com/balooloo/hazelnut</a><br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> and because Installer.app really isn't so much of a package manager, just an installer. (It records what files are owned by which package, but there is no interface to remove packages, handle conflicts, etc.)<br>
</blockquote><div><br>I would add that .pkg are more suitable for system daemons and apps spreads across the system<br>while .app are more suitable for standalone program such as UIs, as detailed below by Charles<br><br>@Vasek: if you're out of (urgent) work, tell me so and I'll point you a few practical examples for generating .pkg<br>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A typical Mac app is removed by deleting the *.app directory, but a command-line tool like NUT would be spread across several directories hard-coded at build time. It is possible to change the shared library (.so -> .dylib) paths to reference files in a local .app directory for a GUI tool, so that's something to think about for the future.<br>

<br>
There is also an init replacement called launchd which we would probably want use to start upsd and upsmon. (There have been a few posts to this list about it.) I have a few attempts at patches to support generating a launchd .plist file in my local Git tree, but they need to hook into autoconf to get the install pathnames.</blockquote>
<div><br>-- arno <br></div></div>