We need to build Mac packages on the fly and it would be convenient if there is a way to create the same on Windows or Linux platform instead of using PackageMaker on Mac. Any ideas?
I don't agree that this is impossible. You could certainly do all the things PackageMaker does on OSX on another OS. It's just a matter of creating these files:
Contents/
Archive.bom
Archive.pax.gz
Info.plist
PkgInfo
Resources/
TokenDefinitions.plist
package_version
en.lproj/
Description.plist
The .plist files can easily be created in Python with plistlib which is now standard in Python. The .bom and .pax.gz are a bit trickier but the rest are all text files.
The .gz part of the .pax.gz file means it is compressed with gzip. This is available on Windows and Linux.
According to the pax man page a pax file can actually be in several different archive formats including cpio and tar, also easy to do in Linux or Windows. PackageMaker seems to create compressed cpio files, at least on 10.6.
The .bom file is a list of all the files in the package and their sizes. It is probably the hardest part to create outside of OSX. BOM stands for Bill Of Materials and comes from the NextSTEP operating system. I haven't been able to find much information about the BOM format but here are some clues: NextSTEP bom man page, OSX bom man page
Edit: I've now implemented a version of lsbom which I've placed in the public domain. The code can be found in Subversion here: https://cauldrondevelopment.com/svn/osxbom/trunk
Perhaps someone can also implement mkbom and then there will be a complete solution. See the header file bom.h in the above code for a somewhat complete description of the BOM file format.
Edit 2: A working version of mkbom has now been implemented and can be found here:
https://github.com/hogliux/bomutils
along with a detailed tutorial on how to create an installer on linux:
http://hogliux.github.io/bomutils/tutorial.html
Also see the question how-to-build-native-mac-os-x-installer-on-a-non-mac-platform.
Nope, you can't. You could do a scripted ssh login and fire it off using osascript so you can automate the whole build from somewhere else, but you can only build for a Mac on a Mac.
You could do all the builds on a Mac, though. It's much easier that way around.
Related
I am using Evolution (flatpak package) as a Personal Information Manager. However, when I try to print an E-Mail as .pdf, I have not full access to my filesystem. I can only save the .pdf in some restricted file tree.
I have used the trick to print the .pdf in the ~/.gnupg folder, and then using the ordinary file manager copy-paste into any folder—But that is no long-term solution.
How could I make the pdf-printer in Evolution have access to the whole filesystem?
Apparently, there is some kind of bug in Evolution concerning this issue (see forum), whereas in other applications such as Inkscape (flatpak) everything runs smooth.
The quickest fix is to add the option --filesystem=home to the running command of Evolution (see forum), namely,
flatpak run --filesystem=home org.gnome.Evolution
Maybe you have to edit your desktop entry of Evolution (See desktop editor)
I am not a Mac owner and am putting myself through a crash course to get up to speed (e.g., reading "Switching to the Mac"), to give you an indication of my current level of understanding. The access I have to a physical Mac is limited, so I am trying to connect as many dots as possible before my next session with my friend's computer.
I have: a file folder containing all resources needed for a self-contained application written with Java (OpenJDK 11, JavaFX 11). The JLINK tool was successfully used to create this file folder, and it holds all necessary Java libraries as well as the code I wrote for the application. The executable resides in a subfolder: /bin. The program runs perfectly well on the Mac when the executable is run.
I want: something that is easy to download, install and run.
I'm unclear about what needs to be done to get this. The road map seems to have two main steps:
the file folder needs to be converted into something that responds as if it were an application (e.g., a Bundle? or an .app?)
the resulting folder-as-executable can be shipped via either .dmg or .pkg
For the second part, I've researched and found tools such as Packages or create-dmg. It seems to me these tools are pretty straightforward and shouldn't be too difficult to learn to use. (Just have to pick one or the other or something similar.)
For the first part, I'm on shaky conceptual ground. I've found info about Bundles, but no tutorials, walk-throughs or examples. It looks like a key step is understanding how to make a proper Info.plist file, but doing this properly looks tricky. Also, I'm not clear on how the resulting Bundle will become an .app file or if it needs to, or if there is another, more direct way to make my file folder be viewed by the OS as an application.
Some hand-holding or references to tutorials or even assurance that I am on the right track (if that is the case) would be much appreciated. Thanks!
The Java Deployment guide from Oracle relies heavily on ANT, but doesn't cover the case of a self-contained, customized JVM via JLINK well enough for me to decipher. So, I've taken the approach of trying to learn/understand the necessary steps using command-line commands.
While creating a Bundle is certainly an option, there is an easier way.
Step one is to make an .app manually. An answer to this question: "How to make a Mac OS X .app with a shell script?" goes over the basic steps. The Java file system that results from jlinking has a folder /bin in which there is a bash file that runs the program. This file should be moved to the outermost folder, and it should be named the desired name of the application. The bash file itself will have to be edited and "/bin" added to the address in last command so that the executable will be found. In addition, the folder itself will have to be renamed to be the same as the bash file, but with .app added as an extension.
The next thing I wanted to have was a custom icon. The question "Include icon in manually created app bundle" shows how to do this.
For the next step I made use of the program "Packages". I'm a bit confused about where I downloaded this from (there seem to be multiple sites), but here is a link to the manual. This tool allowed me to create a .pkg file that, when executed, installs my .app in the Applications folder. Then I compressing the .pkg file (to .zip) and made it available at a URL for downloading.
I've had a friend do a test download and install, and the program works!
This isn't meant to be a complete tutorial, and there are a few steps more that I want to figure out pertaining to sandboxing and sealing, but I believe this is a reasonable roadmap that can be used for simpler jlinked Java applications for Mac distribution.
I have an application that I've written for Windows which I am porting to Linux (Ubuntu to be specific). The problem is that I have always just used Linux, never really developed for it. More specifically, I dont understand the fundamental layout of the system. For example, where should I install my software? I want it to be accessible to all users, but I need write permission to the area to edit my data files. Furthermore, how can I determine in a programmatic way, where the software was installed (not simply where its being called from)? In windows, I use the registry to locate my configuration file which has all of the relevant information, but there is no registry in Linux. Thanks!
The Filesystem Hierarchy Standard (misnamed -- it is not a standard) will be very helpful to you; it clearly describes administrator preferences for where data should live.
Since you're first packaging your software, I'd like to recommend doing very little. Debian, Ubuntu, Red Hat, SuSE, Mandriva, Arch, Annvix, Openwall, PLD, etc., all have their own little idiosyncrasies about how software should be best packaged.
Building
Your best bet is to provide a source tarball that builds and hope users or packagers for those distributions pick it up and package it for you. Users will probably be fine with downloading a tarball, unpacking, compiling, and installing.
For building your software, make(1) is the usual standard. Other tools exists, but this one is available everywhere, and pretty reasonable. (Even if the syntax is cranky.) Users will expect to be able to run: make ; make install or ./configure ; make ; make install to build and install your software into /usr/local by default. (./configure is part of the autotools toolchain; especially nice for providing ./configure --prefix=/opt/foo to allow users to change where the software gets installed with one command line parameter. I'd try to avoid the autotools as far as you can, but at some point, it is easier to write portable software with them than without them.)
Packaging
If you really do want to provide one-stop-packaging, then the Debian Policy Manual will provide the canonical rules for how to package your software. The Debian New Maintainers Guide will provide a kinder, gentler, walkthrough of the tools unique to building packages for Debian and Debian-derived systems.
Ubuntu's Packaging Guide may have details specific to Ubuntu. (I haven't read it yet.)
Configuration
When it comes to your application's configuration file, typically a file is stored in /etc/<foo> where <foo> represents the program / package. See /etc/resolv.conf for details on name resolution, /etc/fstab for a list of devices that contain filesystems and where to mount them, /etc/sudoers for the sudo(8) configuration, /etc/apt/ for the apt(8) package management system, etc.
Sometimes applications also provide per-user configuration; those config files are often stored in ~/.foorc or ~/.foo/, in case an entire directory is more useful than a file. (See ~/.vim/, ~/.mozilla/, ~/.profile, etc.)
If you also wanted to provide a -c <filename> command line option to tell your program to use a non-standard configuration file, that sometimes comes in real handy. (Especially if your users can run foo -c /dev/null to start up with completely default configuration.)
Data files
Users will store their data in their home directory. You don't need to do anything about this; just be sure to start your directory navigation boxes with getenv("HOME") or load your configuration files via sprintf(config_dir, "%s/%s/config", getenv("HOME"), ".application"); or something similar. (They won't have permissions to write anywhere but their home directory and /tmp/ at most sites.)
Sometimes all the data can be stored in a hidden file or directory; ssh(1) for example, keeps all its data in ~/.ssh/. Typically, users want the default kry name from ssh-keygen(1) so ssh-agent(1) can find the key with the minimum of fuss. (It uses ~/.ssh/id_rsa by default.) The shotwell(1) photo manager provides a managed experience, similar to iPhoto.app from Apple. It lets users choose a starting directory, but otherwise organizes files and directories within as it sees fit.
If your application is a general purpose program, you'll probably let your users select their own filenames. If they want to store data directly to a memory stick mounted in /dev or /media or a remote filesystem mounted into /automount/blah, their home directories, a /srv/ directory for content served on the machine, or /tmp/, let them. It's up to users to pick reasonable filenames and directories for their data. It is up to users to have proper permissions already. (Don't try to provide mechanisms for users to write in locations they don't have privileges.)
Application file installation and ownership
There are two common ways to install an application on a Linux system:
The administrator installs it once, for everyone. This is usual. The programs are owned by root or bin or adm or some similar account. The programs run as whichever user executes them, so they get the user's privileges for creating and reading files. If they are packaged with distribution packaging files, executables will typically live in /usr/bin/, libraries in /usr/lib/, and non-object-files (images, schemas, etc.) will live in /usr/share/. (/bin/ and /lib/ are for applications needed at early boot or for rescue environments. /usr might be common to all machines in a network, mounted read-only late in the boot up process.) (See the FHS for full details.)
If the programs are unpackaged, then /usr/local/ will be the starting point: /usr/local/bin/, /usr/local/lib/, /usr/local/share/, etc. Some administrators prefer /opt/.
Users install applications into their home directory. This is less common, but many users will have a ~/bin/ directory where they store shell scripts or programs they write, or link in programs from a ~/Local/<foo>/ directory. (There is nothing magic about that name. It was just the first thing I thought of years ago. Others choose other names.) This is where ./configure --prefix=~/Local/blah pays for itself.)
In Linux, everything is text i.e. ASCII.
Configuration is stored in configuration files which normally have .conf extension and stored in /etc folder.
The executable of your application normally resides in /usr/bin folder. The data files of your application can go to /usr/lib or folder in /usr/ folder.
It is important to consider which language you are writing your application in. In C/C++ a custom makefile is used to do installation which copies these files in respective folders. The location of installation can be tracked by tracking the .conf file and storing the location while generation using bash script.
You should really know bash scripting in order to automate this everything.
Other systems such as Debian have code to load individual files inside /etc/emacs/site-start.d at startup. Now after install Magit using Homebrew there are files in /usr/local/etc/emacs/site-start.d that should be loaded at Emacs startup. Does stock Emacs have a function to do this, or must the functionality be ported from debian-startup.el?
If you don't know exactly what is being talked about here, please don't suggest arbitrary Elisp snippets to load files from a directory. Thank you!
/etc/emacs/site-start.d is a Debian addition to the load-path and startup process. I'm not sure whether it is self-contained in debian-startup.el, but /usr/local/share/emacs/site-lisp/site-start.el would be the standard location where something similar could be done (by using an arbitrary snippet to load files from a directory).
I am planning to develop a cross-platform script. On Linux and other operating systems, it will store configuration in XDG_CONFIG_HOME and data files (specifically, downloaded plugins) in XDG_DATA_HOME. On Windows, it will use APPDATA for both (unless someone has a better idea). However, what would be the proper thing to do on Mac OS X?
On my first glance through a handy Macbook's ~/Library directory, I saw Preferences and Application Support folders. I was originally planning to use those, but Preferences seems to just contain plists with reverse domain names like com.apple.foo.bar.baz.plist, and every folder in Application Support corresponds to a bundle in /Applications, so I'm not sure how well the system would react to files that don't match its standards. Storing them directly in ~/Library might be an option, but I don't want to pollute it with a stray myscript.conf file if there's a better place for it.
Where should I store these files? (And please don't say just ~/.myscript. I know it's the Unix tradition, but it annoys me to see random dotfiles in the home directory.)
Comparing Apple's documentation for the various paths to the XDG Base Directory specifications approximates to the following locations:
XDG_CONFIG_HOME ▶︎ ~/Library/Preferences/
XDG_DATA_HOME ▶︎ ~/Library/
XDG_CACHE_HOME ▶︎ ~/Library/Caches/
Mapping XDG Base Directory Specification locations for "My App" on Mac OS X could look like this:
XDG_CONFIG_HOME ▶︎ ~/Library/Preferences/name.often.with.domain.myapp.plist
XDG_DATA_HOME ▶︎ ~/Library/My App/
XDG_CACHE_HOME ▶︎ ~/Library/Caches/My App/
These mappings seem pretty reasonable but they aren't exact. Some kinds of cache or data may be appropriate for ~/Library/Application Support/My App, and other may be best in the temp locations or the App bundle. All of it is by convention and the same reasons for using the best XDG_ locations apply to using the best locations on the Mac OS X system.
Your annoyance at ~/.myscript is in line with Apple's guidelines: "Don't pollute user space".
References:
Mac OS X Reference Library: Where to Put Application Files
Mac OS X Reference Library: Important Java Directories on Mac OS X
I agree with OJFord's comment: if you are writing a script (I think this applies to all CLI-only application), simply follow the XDG Base Directory would be better.
Rationales:
Names in XDG_CONFIG_HOME are typically small-case bare-names like git; the ones in ~/Library/Preferences/ are typically files named with reverse domain name notation like com.apple.AppStore.plist, or directories named in title case like Blackmagic Design.
GUI applications have been following macOS conventions when they are placed in /Applications. You don't place your script in /Applications; you place them in UNIX-specific directorys. Better to be consistent.
~/Library/Preferences/ is full of .plists. No cross-platform script that I know is using property lists.
Users may want to sync cross-platform configuration and macOS-only one separately.
For example, Git places their config file in XDG_CONFIG_HOME/git/config, not in ~/Library/Preferences/Git/config. Makes sense to me.
note
I made the point only for configuration files ($XDG_CONFIG_HOME) and data files ($XDG_DATA_HOME); for cache files it gets subtle. According to How-To Geek, ~/Library/Caches directory is excluded from Time Machine by default. I don’t care about cache folder since I back up neither directories anyway; but for ones who care, I recommend them to link ~/.cache to somewhere in the default cache folder, such as:
cd ~; mv .cache ~/Library/Caches/XDG-cache; ln -s ~/Library/Caches/XDG-cache .cache
I would use ~/Library/Application Support/script_name/. The subdirectories inside Application Support are used conventionally by various apps, including Apple's own softwares. But it's not enforced by the OS and not tied to apps inside /Applications. So you're perfectly free to create your own directory in it.
For the directory structure of OS X in general, see this Apple document.
Here are the choices made by the os package in golang:
XDG_CACHE_HOME → $HOME/Library/Caches
XDG_CONFIG_HOME → $HOME/Library/Application Support