> Minus: yet another proprietary package manager, bypassing the operating system's software management subsystem (operational maintainability)

False. Nimble installs packages only in the current user's home.

It's one of the few package managers that does not encourage the dreadful "sudo pip/npm/... install"

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)

i must admit that i'm not a big fan of nimble (nim's package manager; for a few reasons) but on the other site you have apt, pacman, yum, whatelsenot, afaik most of them are not even able to install two versions of the same library side by side. The situation is so bad that most applications these days are packed with `flatpack` or something else, because of the so broken linux package management...

In contrast to eg. npm nimble is superfast.

> most of them are not even able to install two versions of the same library

That's entirely by design.

Distributions exist to provide a set of packages that are well tested, and work reliably, together.

And then guarantee that such set will stay the same and receive timely security updates for 3 or 5 or more years so that people can reliably use it in production.

and in the real world you do configure; make install then ;) edit: or docker every one i've met so far, uses docker as a kind of "package manager". Database? Oh year use this docker image, elastic search & kibana? shure docker. What they actualy want most of the time is: an easy way to install this stacks, in an non ancient version, where i can actually use the stuff i need to use.

"and in the real world you do configure; make install then"

In the real world, one gets an existing RPM .spec file, edits it for the required source one is about to build, and then runs:

  rpmbuild --clean -ba software.spec

once one has RPM's there is no need for Docker, as multiple applications can be cleanly installed, upgraded or removed on the system, and the entire system can be automatically PXE booted and provisioned by Kickstart without a single line of glue code.

Say no to hacking with Docker and make install instead of formal system engineering.

A shared object library is supposed to use linker map files during her creation to declare interface versions, so that the run time linker can request and obtain the correct version of the interface. Like all the traditional UNIX operating environments solved it: no need for multiple versions, one library contains all versions and the run time linker maps in the requested code. See how illumos does it. Search for linker map files.

i will thank you