You bring up two good points.
1) In the spirit of /tmp/opt, I have an early version of AB2.1 that uses the /tmp/ab-solution link. It makes everything so much simpler in all scripts.
But I felt it as preposterous to link my ad-blocker to the /tmp file structure at the time. AB2.1 was meant to be the update for AB2.x and was never released.
It evolved into what is now the current version: AB-Solution 3.
With the popularity AB gained with the current version, I look at it differently and am also bolder in what may be appropriate for 'my little ad-blocker script'. The /opt/ab-solution link is planned for the next major version, AB4.
But I don't support your suggestion to freely select the name of the install directory. After all, it is the coders decision how to name the application and it's underlying folder and file structure.
I'm sure you agree with me that no one would ask Linus Torvalds to build in a user defined name for the /etc directory, but within /etc, it's all at the coders discretion.
2) AB3.1 will support 'entware', 'entware-ng' and finally, the 'entware-ng.arm' install folders. All entware-setup scripts out there will by default install into one of these three folders.
AB-Solution will install a new installation into the /entware directory, unless a already working installation is found in /entware-ng and /entware-ng.arm.
To determine if AB has to add this to the post-mount I need a reliable way of finding out what the directory is called and make the decision to add or overwrite the entries in post-mount.
AB also inoculates the entware install by writing the /tmp/opt/etc/absolution.sig file. This is to make sure AB does not alter the S80pixelserv-tls if another Entware install is plugged in.
This is my philosophy and I fared very well with it.
So, my question is, would you ask the Entware maintainers to build in an option in their script to user define the install directory? Probably not.
We'll probably never see eye to eye here, but please take my input in the spirit of "continuous improvement." I think the fundamental issue we're having is I'm a "play nice in the sandbox" kind of guy, you're of the "for your own good, I'll define your sandbox for you." I'll just make a few more comments and go away.
1) It appears we may still be talking past each other. I'm not asking to "freely select the name of the install directory," but rather just the initial location of it. I think you'd be hard pressed to find any other legitimate Linux add-on application that doesn't support that capability. You can still require that it be installed in "adblocking," and totally define the underlying directory and file structure, but let me put it in an initial subdirectory of my choosing, at least one level lower than the directory at the mount point.
The motivation is simple. The AsusWRT implementation of Samba creates a share for all directories at that 'just above the mount point' level (i.e. those directories in the root of each USB volume). It makes no sense to create a Samba share for the 'adblocking' folder, and just adds muddle to those of us that use Samba and like to keep a neat and tidy look. By placing that adblocker folder one level deeper in the hierarchy, that Samba share is never created.
Your comparison to Linus Torvalds is apples to oranges. He defined the OS, you're just an add-on application. I think a more relevant comparison is to a standard Linux add-on app like minidlna. You can install the application anywhere you choose (it doesn't care), and it learns about its required directories through its .conf file. There is a default location for its .conf file, or you can specify it on the command line. In the .conf file, one line specifies the location of the db_dir, however once specified, minidlna owns the structure of the directories and files contained therein.
That overall philosophy and structure is repeated across the vast majority of UNIX/Linux add-on applications, and I would encourage you to think about applying that to AB, to give it a more mature look and feel.
2) Let me start with:
"Would you ask the Entware maintainers to build in an option in their script to user define the install directory?" I don't need to, it's already fully supported!
The front-end install script(s) you're referring to don't come from the entware repository. There are numerous variations floating around, all just provided as a convenience to new users. You have one hard-coded in your AB scripts, there is one that comes with the Merlin firmware, and there are plenty more on various external web sites. They all boil down to just 3 steps:
- define an install directory somewhere on a Linux file system
- link that directory to '/tmp/opt' (the "magic hook" built into AsusWRT-Merlin)
- download and run the "real" installer script from the Entware repository (this script varies by processor architecture)
Nowhere in the "real" entware install script (the one downloaded from pkg.entware.net) is there a reference to any flavor of "entware" directory. It simply installs to /opt (which has been pre-linked to '/tmp/opt' in the firmware). I keep saying, this is truly an elegant design, and is clearly embraced by the Entware development team.
So my point is, the designers of Entware took the "play nice in the sandbox" approach of not caring where the entware package is installed, as they never directly reference that directory. I'm not suggesting you change your entware install script; installing to 'entware' is fine, especially for novices. But I argue that so long as I have a valid entware installation (and I do), you shouldn't care where it's located either. Just do your checks relative to '/opt' and all is well.
And I applaud the step you took "… writing the /tmp/opt/etc/absolution.sig file." Note that you're referencing the '/opt' path. That check doesn't care where entware is installed, you just know it's inside the currently active entware installation structure.
Finally, you're probably wondering why I even care about all this. First, philosophically, I just prefer the "open sandbox" that permeates Linux, the open-source culture, and certainly RMerlin and his customization of AsusWRT. It is truly an elegant design, and the Entware designers are of similar mindset with their minimal hooks into the OS.
Secondly, my personal desktop environment is Windows-based, and I interact with the router primarily through Samba. I like to keep that Samba space clean, so I only have 2 shares on the Linux filesystem on my router: the "entware install folder," and an 'app' folder. The 'app' folder contains add-on applications I run that didn't come from entware (just to keep the entware directory structure pristine, and I know I can reinstall entware at any time and not impact my non-entware application files). Logically, AB should also be located in my 'app' directory (in a subdirectory 'adblocking') but you explicitly don't allow that (hence my 1st request above).
The second thing I did was rename 'entware' to 'opt'. That way, that directory is referenced as "opt" via Samba (and thus in Windows-based apps and scripts running on my various PCs), and "/opt" via a telnet/ssh prompt or in router-based scripts. It just seems cleaner and makes more sense to me that way. I also created a symbolic link under /opt (within the "entware directory") to my 'app' directory. That allows me to reference all objects under 'app' as '/opt/app/…', yet another elegant extension isolating the underlying filesystem structure from the higher-level applications.
It took exactly 2 commands to move 'entware' to 'opt', (rename the directory, then update the link in post-mount), and had zero impact on anything else. [BTW, just as a test, I also did a clean install of entware to "opt" and as expected, it ran error-free.]
Off my soapbox. If any of that makes sense, cool. If not, no problem. Perhaps some of what I've written will help others better understand this environment. Many of us techies love to learn and understand what's going on under the covers and customize it to our liking. It's been fun for me to explore, learn, and tinker with my AsusWRT-Merlin router, my current sandbox. And finally, just saying, some minor changes to AB to allow for a lighter footprint just might increase the appeal of AB to a broader range of users.
