Question on Entware and /opt directory linkage

[bengalih]

I've got a question/topic for discussion that is interesting to/bothering me:

Why does Entware co-opt the entire "/opt" folder, being that it is just a single software package (albeit a repo for multiple packages)?

From my time working with traditional unix systems, "/opt" has always been the directory/mount point for 3rd party software packages. While Entware certainly would fall into this category, I would expect to find it at "/opt/entware" and not have "/opt" be a link directly into the entware folder.

A user/admin may wish to install another package outside of entware onto their system and the usual place for this would be /opt. On an asuswrt-merlin install (with entware) this would place that package within the entware structure, which is just mucky. If one were to wipe-out (or simply want to back-up) their entware install, this 3rd party package is now at risk of being removed and/or included when the intent was not to do so.

I would think it would have been closer to unix standards to link /opt either to the entire flash drive or at least to an /opt folder within it where Entware would be installed. Then, instead of there being years and years of development with things pointing just to "/opt", they would be pointing to "/opt/entware" instead.

Was this just a bad decision back at the very beginning and now it is too hard to fix? Or is there some better explanation of why it was done this way.

It is unclear to me at this point who is actually responsible for Entware, as the github page redirects all requests back to platform specific pages like here. So, I don't know if @RMerlin is the correct person to address this, or if there is a better place I can ask this question.

I had asked about this in @thelonelycoder Diversion thread, and got some feedback, but I don't think continuing in that thread is conducive to getting the answers I'm looking for.

Would appreciate any feedback on the "why" without simply being told "well that's the way it is."

 

[bengalih]

And to add to this discussion a pivot point that may be helpful to more people other than just my idle curiosity:

Because of this limitation/strangeness that I mention in the OP, what are the recommended ways (or simply just the ways) that you embedded linux gurus handle placing files?

- Do you make an /opt folder at the root of your flash drive (at the same level as /tmp/mnt/flash_drive/entware) and simply place what you need there? Do you place an /etc folder here too for custom configs?

- Do you simply install all your packages directly into the entware folder (/tmp/opt) even if they aren't Entware packages? Do you utilize the /etc folder in there?

Obviously there are some unique challenges for keeping persistent data on an embedded device and certain concessions might need to be made from a traditional way of handling them on a unix system. I'm curious what people have found to be the most logical method for ordering the persistent files.

 

[cmkelley]

And to add to this discussion a pivot point that may be helpful to more people other than just my idle curiosity:

Because of this limitation/strangeness that I mention in the OP, what are the recommended ways (or simply just the ways) that you embedded linux gurus handle placing files?

- Do you make an /opt folder at the root of your flash drive (at the same level as /tmp/mnt/flash_drive/entware) and simply place what you need there? Do you place an /etc folder here too for custom configs?

- Do you simply install all your packages directly into the entware folder (/tmp/opt) even if they aren't Entware packages? Do you utilize the /etc folder in there?

Obviously there are some unique challenges for keeping persistent data on an embedded device and certain concessions might need to be made from a traditional way of handling them on a unix system. I'm curious what people have found to be the most logical method for ordering the persistent files.

Agree this is a better place to discuss ... I didn't see this until I got home tonight or I would have replied here instead of in the Diversion thread. I think almost everywhere below where I say Entware you can add "or Optware" in your head. I'm honestly not trying to pick at you, I'm trying to explain why I think Entware "taking" /opt is not the bad thing you appear to think it is. Also, as a result of looking into this, I finally found out why rc.unslung is named that.

I do not have an /opt folder on my USB. Other than /entware I have a backup directory that I backup /jffs to nightly, and it looks like Skynet and some other script keep a couple data directories on the USB root as well. I also have a directory I share to my network to move stuff back and forth to the router.

As far as installing programs, single programs go in /opt/usr/bin or /opt/usr/sbin since Entware and its packages already use these in addition to /opt/bin and /opt/sbin. For programs with support files, I put the executables in /opt/usr/bin or /opt/usr/sbin and put the support files in their own directories in /opt/share, which seems to be Entware's standard, akin to the BSD method of using /usr/local/share for support files (or Linux's /opt folder). Custom config files go in /opt/etc. Heck, I even have a script that wipes /tmp/home/root and symlinks /opt/root to it when the USB is mounted so my history and other stuff isn't lost on reboot. Granted, I'm 100% certain I'll never remove Entware, so leveraging its directory structure avoids complication.

How would you install a package without Entware anyway? There's no compiler in the firmware, so you'd have to cross-compile on another machine. I only did a short check, but I didn't even see a C/C++ compiler in Entware, only Erlang, Lua, and Python. The firmware doesn't include a package manager either, so the only available package manager is Entware's opkg.

The router is not designed to have multiple user accounts, just the one root user. I seem to recall Merlin saying that creating additional accounts was actually not a good idea for some reason, but it escapes me now.

Optware started using /opt in 2004, Entware continued when they forked from Optware, and I'm not at all convinced at all that it was a bad decision to just take /opt, or that it is even to this day. Optware was designed as an extension to the firmware of a NAS; it is not a single application, it is many applications. You'd no sooner remove it than delete your /bin directory.

I can't say that I know for a fact the reasons they chose to just take /opt, but logically, since the root filesystem is in firmware and thus not writeable, you can't extend the firmware by simply writing to /bin or /sbin, and even if you could, it wouldn't be persistent, which is the current case for /etc. The room for the firmware is limited, so growing the firmware significantly isn't possible either. Going forward with that logic, if they did want to follow the semi-standard usage of /opt, the firmware extensions went in /opt/bin and /opt/sbin. If that's true, then maybe originally that's all there was to Optware, just /opt/bin and /opt/sbin (perhaps also /opt/lib?), with their configuration files in /opt/etc, and the rest grew up around it?

I say "semi-standard", because interestingly enough, Minix, which Linus used in developing Linux, does not have an /opt directory! What Unix systems other than Linux have you used that have an /opt directory? I don't have any VMs setup right now that aren't Minix, Linux or BSD.

I ran a couple Linux VMs and they seem to use /opt like BSD uses /usr/local/share, i.e. nothing in /opt is in the path, so I'm guessing they would normally expect 3rd party application to put executables in /usr/bin or /usr/sbin. Note that these, along with /bin and /sbin, are part of the read-only root filesystem in the router firmware, presumably so they don't have to be copied into memory. So if you didn't have entware on your router, where would you propose to put 3rd party applications so they were executable at the command prompt? Add a bunch of /opt/program directories to the path? Or add /opt/bin and /opt/sbin?

The principal people "responsible" for Entware are listed in the GitHub Entware "people" page; Alexander Ryzhov (ryzhovau), Vladislav Grishenko (themiron), and zyxmon. I have no clue if any of the three would be responsive to inquiries. Optware has its own GitHub page as well, but doesn't list anyone in its people page.

As an aside, while I 100% understand why the router manufacturers use Linux as a basis for the firmware, if I was doing it, and had the money to hire some hardcore coders, I'd have used OpenBSD and pf. I'd probably also be broke and out of business, but that's another story.