Linux port - might I help?

[ReneFroger]

As stated in readme:

um is currently available only for MacOS.

LInux mostly use same tools and file hierarchy as MacOS. Perhaps I might help to create Debian/Pacman packages of um. But I need to know what the known limitations are to port to Linux, then I'll glad to help to figure it out.

[pjz]

FWIW, it seems to run fine under linux, though it depends on having pandoc installed.

[ktm5j]

I was going to say the same thing.. seems like it shouldn't be too much work, I would volunteer to help with this.

[ktm5j]

@pjz yep everything seems to work.. you can copy bin/, lib/, and libexec/ to whatever path prefix, I think all that's needed is some script or package to put everything into place for the user.

It looks like the rakefile only sets up docs.. I don't know a ton about ruby, would a rakefile typically be used for install/setup similar to how you would use gmake/makefile? Or I guess you could make distribution packages pretty easily.

[pjz]

Ideally it would be packaged up somehow.... a gem or a deb or something.

[StephenBrown2]

Or flatpak/appimage

[leggettc18]

I would also be willing to make a package for Solus. I don't have much history contributing to OSS but this could be a good start.

[leggettc18]

@ktm5j If I understand correctly the Rakefile is mostly used for the Developer to automate certain tasks. For example @sinclairtarget has a task in it for turning md files into man files so he could write man-pages for um using Markdown format instead of roff format. It probably wouldn't be of much help in installing the program onto a Linux Distribution, at least not in this case.

Someone feel free to correct me if I'm misunderstanding this.

[sinclairtarget]

You are absolutely welcome to attempt a Linux port. I really don't think there's anything standing in the way of that. The MacOS-specific stuff is mostly the Homebrew installation stuff.

The Rakefile is only used for generating um's own documentation. So it shouldn't ever be run by someone just using the program.

[leggettc18]

I just made a Solus Package for it on my machine, but it wouldn't work unless I were to create a /usr/templates folder with the template files in it. I saw where you took the files out of the /usr/share folder because of Homebrew. However, on Linux, a sub-directory of /usr/share(/um perhaps) would be the perfect place to put it. It would be FHS compliant at the very least. Would that be doable with Mac OS or would we need to get the path to the template files differently depending on OS @sinclairtarget? I don't have a Macbook to be able to test that myself.

[He-Ro]

As @leggettc18 pointed out, running um on Linux is no problem, since it is written in Ruby and that is of course available. Generating the manual pages for um with the Rakefile also works, the difficult part is the Packaging of um. This is the first time I have seen the libexec directory, I needed to look up whether it was a standard directory, which it is not on e.g. Arch Linux, but on a Mac it is listed in the man page hier, let me quote from it:

HIER(7)              BSD Miscellaneous Information Manual              HIER(7)

NAME
     hier -- layout of filesystems

DESCRIPTION
     A historical sketch of the filesystem hierarchy.  The modern OS X filesystem is documented in the ``File System Programming
     Guide'' available on Apple Developer.

     /             root directory of the filesystem

     /bin/         user utilities fundamental to both single-user and multi-user environments

[ snip... ]

     /usr/         contains the majority of user utilities and applications

                   bin/      common utilities, programming tools, and applications
                   include/  standard C include files

                             arpa/       C include files for Internet service protocols
                             hfs/        C include files for HFS
                             machine/    machine specific C include files
                             net/        misc network C include files
                             netinet/    C include files for Internet standard protocols; see inet(4)
                             nfs/        C include files for NFS (Network File System)
                             objc/       C include files for Objective-C
                             protocols/  C include files for Berkeley service protocols                                                           
                             sys/        system C include files (kernel data structures)                                                          
                             ufs/        C include files for UFS                                                                                  

                   lib/      archive libraries                                                                                                    
                   libexec/  system daemons & system utilities (executed by other programs)                                                       
                   local/    executables, libraries, etc. not included by the basic operating system                                              
                   sbin/     system daemons & system utilities (executed by users)       
[ snip... ]

So I am not sure, whether the Ruby files in there should actually go there, as they are not meant to be used by other programs (as far as I understand). Moving them to somewhere else (e.g. the lib/um path) would make it much easier for packaging, since it would be only one directory to take care of instead of two. Also I do not want to create a non-standard directory on my Arch system. Second is the templates folder as already mentioned. Putting that into share/um/templates would also be required, since I do not want to create the directory /usr/templates/. Another way of solving these issues would be if we could have something like configure in C programs, where we tell it where to put the different files, but since they are referenced relatively that could be a little troublesome. The way I packaged it now (https://aur.archlinux.org/packages/um-git/) is to put it into /opt/um, but that does not integrate into the system at all and I would like to be able to change that.

[leggettc18]

Hmm. My Solus installation already had a libexec folder. But that's a different distro so it might just be a difference in packaging preferences. Regardless, it should be possible to determine what operating system the program is running on and setting the path variables according to that at the very least. I agree a configure script of some sort would probably be better though.

[He-Ro]

@leggettc18 Yeah, after some more research I guess libexec isn't uncommon after all. So I agree that having some way to configure the paths at install time would be the best approach at portability. Of course this would mean to some degree more effort in installing for those where it already works. They would also need to invoke a configure script (or something else), which they were not required to do before hand.

[leggettc18]

I can't speak for Homebrew, but any Linux package managers would handle that for the users. Since this is currently only on Homebrew now would be the time to do it.

I think the best course of action might actually be turning this into a Ruby gem. Solbuild has useful shortcuts that make installing Ruby gems via eopkg really easy. I'd be willing to give it an attempt, but it'd take me a bit to figure out exactly how.

[He-Ro]

Since the project is now a Ruby Gem it is quite easy to package it. I created a AUR package for Arch Linux which is available here: https://aur.archlinux.org/packages/um-git/ Fellow Arch users please let me know in the AUR comments if there is some way to improve it!

[iajrz]

If this is in AUR, and it's being used in Arch - doesn't that mean that um effectively runs on Linux? What's left to port?

[HaleTom]

That's a bit like saying it runs on Amiga so it effectively runs on a computer...

I'm happy as an Arch user, but other Linux users may want in on the action.

An AppImage may be a universal solution.

[iajrz]

I disagree with the metaphor - Linux distros are more alike between them than Amiga and any Desktop computer. But more importantly, porting and packaging are distinct issues.

Porting (as in changing the code so that it can be effectively used on a particular platform) is not necessary at this point. If my memory doesn't betray me, it wasn't an issue at any point for Linux - although it was for Windows given some pandoc idiosyncrasy.

The work that's left to do is packaging.

Initial context for this issue was the state of the Readme file at the moment; given the maintainer only tested on MacOS, he could only vouch for that. Soon enough someone got it running on Linux, and at some point the porting and packaging issues got conflated.

AppImages, just like .debs, .rpms, snaps, etc. are packaging solutions.

Packaging doesn't quite seem to be a burden to be borne by the maintainer, nor within the scope of this repository. Whomever wants to build a package for a particular manager may do well to create their own repo, for packaging is its own project.

[sinclairtarget]

FWIW, the Homebrew package, which is the only one that I maintain, is in a separate repo. At this point I think um itself is easy enough to package that there shouldn't be any more major changes happening in this repo to support "porting"/packaging. So it's just a matter of having someone make a package for your platform (which would happen outside this repo).

So I'm going to close this issue for now, but feel free to open another in the future if something about the way um currently works makes packaging impossible for some platform.