-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Linux port - might I help? #6
Comments
FWIW, it seems to run fine under linux, though it depends on having |
I was going to say the same thing.. seems like it shouldn't be too much work, I would volunteer to help with this. |
@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. |
Ideally it would be packaged up somehow.... a gem or a deb or something. |
Or flatpak/appimage |
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. |
@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. |
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 |
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. |
As @leggettc18 pointed out, running um on Linux is no problem, since it is written in Ruby and that is of course available. 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 |
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. |
@leggettc18 Yeah, after some more research I guess libexec isn't uncommon after all. |
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. |
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/ |
If this is in AUR, and it's being used in Arch - doesn't that mean that |
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. |
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. |
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. |
As stated in
readme
: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.The text was updated successfully, but these errors were encountered: