oh, guess I shouldn't implement that[1] then :)

To be honest, now that I'm thinking about it again, I think you're totally right.

1 - https://github.com/nim-lang/nimble/issues/80

If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment (like Kickstart, Jumpstart, or AutoYaST) and you create more work for every system engineer in existence because they have to finish your work for you, namely integration of your software (nim language) into the OS.

For every platform nim supports, native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided. This is not some whim, it's a formal system engineering specification. See LSB FHS, /opt, /etc/opt and /var/opt sections, or the illumos filesystem(5) manual page for the same. (Why aren't you as a third party supposed to deliver software into /usr as you intend in that Github issue?)

If you do not do it this way, it will impede adoption because it's one thing for a developer to play around in a language and another for a system engineer to make it operational: system engineers' time is usually in extremely short supply, and if they have to package your language for you, they could easily just move on to writing software in a different language that they can mass-provision natively, and nim will stay an underdog. Operational maintainability is the end goal, means mass deployment without extra code or software like Docker, only using native subsystems. Sooner or later things must go into production.

Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.

You seem to be confusing /opt and /usr.

> native operating system package(s), delivering into /opt/nim (and system-wide configuration into /etc/opt/nim) should be provided

No, native package managers should install binaries in /usr/[s]bin and libraries under /usr

> Never bypass OS packaging. Unless you are an OS vendor, never deliver anywhere into /usr, not even /usr/local.

+1

"You seem to be confusing /opt and /usr."

It is very unfortunate for me that it seems this way to you, but as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case.

"native package managers should install binaries in /usr/[s]bin and libraries under /usr"

Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr: by doing so, one risks destroying or damaging systems in production in the case where the vendor decides to deliver their own version of the same software, and the vendor's upgrade overwrites one's own software and configuration. Long story short: don't deliver your unbundled software into someone else's space. /usr belongs to an OS vendor and to that vendor alone (vendor in this context also includes volunteer operating system projects one is not a part of).

/opt, /etc/opt and /var/opt exist for a reason. Refer to the filesystem(5) manual page on illumos and the LSB FHS specification, sections 3.13., 3.7.4. and 5.12.:

http://illumos.org/man/5/filesystem

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#opt...

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etc...

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#var...

section 3.13.2., Requirements, explicitly states:

No other package files may exist outside the /opt, /var/opt, and /etc/opt hierarchies except for those package files that must reside in specific locations within the filesystem tree in order to function properly. For example, device lock files must be placed in /var/lock and devices must be located in /dev.

http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#req...

> as someone doing precisely this kind of engineering for almost three decades, I can assure you that this is not the case

Same here.

> Unless one is an operating system vendor (like Joyent, redhat, SuSE, Debian, Canonical, CentOS, ...) third party and unbundled applications must never be installed into /usr

That's what I wrote: "native package managers should install binaries in /usr/[s]bin and libraries under /usr"

"native" as in: provided by the distribution. Not third party.

https://github.com/nim-lang/nimble/issues/80 is about using /opt/nimble and you wrote "If you implement that, you instantaneously take away the ability to deploy applications through OS's automated deployment", hence the confusion.

""native" as in: provided by the distribution. Not third party."

It was a misunderstanding then: I thought native meant the packaging format native to the OS, not packages which come with the OS (bundled software).

Issue 80 from what I understood is about nimble, a packaging format proprietary to one programming language, providing system wide installation capability; this would indeed preclude using native provisioning technologies because those use the OS's native packaging format and hence know nothing of "nimble".

It's not false: installing any kind of software without using OS packaging, even in one's home directory makes it a hack. It's working for you in your home directory; what if it now needs to work for everyone, or if it needs to be deployed without any human interaction whatsoever?

Nimble is used only at build time for libraries and few tools. Packaging binaries for production is not its use-case.

Ever worked at a financial, military or an intelligence institution? For example, what if the system where the software must be built has no connection to the internet?

Resisting creation of operating system packages, even for dependencies is silly, because doing so is not hard at all: all it requires is reading some documentation, but the knowledge gained can be reused over and over and over again for the rest of one's career. Learning different OS packaging systems is an investment which pays hefty dividends.

I fully agree. I worked on systems that are not connected to the Internet for security reasons and receive "offline" security updates using distribution packages.

It's also very common in security-sensitive environments to give blanket approvals to specific distributions and prohibit cowboy deployments.

(I'm not sure why you are replying to my post)