Build-time option to automatically uninstall NickelMenu if all configuration files are removed

[NiLuJe]

Sounds sensible ;).

I'd make it trip only if the actual folder is gone, though.

[pgaskin]

I'd make it trip only if the actual folder is gone, though.

That's a good idea. It solves one of the potential issues I was thinking of.

The other thing is for people who install libnm manually (i.e. without the doc file). We don't want it deleting itself right away, which is why I think this should be a compile-time option, but it'd be nice to find a solution for this which can be built-in without adding too much unnecessary complexity.

[NiLuJe]

Hmm, something along the lines or not tripping it either if it's the first time this version of libnm has been loaded?

The only thing that comes to mind right now would involve hiding a sentinel file somewhere to record the version that's been loaded and checking that. That's not terribly pretty :s.

[pgaskin]

The only thing that comes to mind right now would involve hiding a sentinel file somewhere to record the version that's been loaded and checking that. That's not terribly pretty :s.

Well, something slightly prettier, but more hacky, would be to use the file modification date on nm to detect if it was manually installed or installed from the release (by setting a custom timestamp when packing the KoboRoot).

[pgaskin]

If you're fine with compiling from source for your OCP packages, I'll add this as a flag. Otherwise, I'll close this for now.

Edit: Alternatively, I can push binaries compiled with this flag to my server on each commit.

[NiLuJe]

If you're fine with compiling from source for your OCP packages, I'll add this as a flag. Otherwise, I'll close this for now.

Edit: Alternatively, I can push binaries compiled with this flag to my server on each commit.

Either works for me ;).

Second approach is evidently less work for me, but may confuse users re: the asset list in the Releases page? (c.f., the kobopatch shenanigans).

[pgaskin]

Second approach is evidently less work for me, but may confuse users re: the asset list in the Releases page? (c.f., the kobopatch shenanigans).

As in, on my own server (*.geek1011.net), not GH releases.

[NiLuJe]

Second approach is evidently less work for me, but may confuse users re: the asset list in the Releases page? (c.f., the kobopatch shenanigans).

As in, on my own server (*.geek1011.net), not GH releases.

Oh, yeah, that works, too ;).

I'd be partial to a filename (or URL) with the version string (as in, the tag, not a full git describe) somewhere in it to cross-ref w/ the public releases ;).

[pgaskin]

I'd be partial to a filename (or URL) with the version string (as in, the tag, not a full git describe) somewhere in it to cross-ref w/ the public releases ;).

Have a look at nm.storage.geek1011.net and .drone.yml.

[NiLuJe]

Have a look at nm.storage.geek1011.net and .drone.yml.

That'll do just fine, thanks ;).

[NiLuJe]

Quick question: what's the difference between upload-build and upload-commit?

[pgaskin]

One uploads to a dir named after the build number, the other is after the commit sha, and upload-tag is based on the tag.

Once I implement this, the built files will go into a subdir named after the flag.

[NiLuJe]

Okay, better question then ^^: what does the build number reflects? Simply an ever-increasing counter?

[pgaskin]

Yes (https://cloud.drone.io/geek1011/NickelMenu).

[NiLuJe]

Okay, here's a crazier idea: binary patch a flag during the failsafe restore (say, a global bool or something) to flip it from false to true and use it to check if this iteration of the library has already been initialized (i.e., patched) once...

[NiLuJe]

Or, mildly less crazy, restore the lib with a different filename in the failsafe and use the lib's name as an indication that it's a fresh install?

EDIT: But then how do you deal with updates? Can we clobber the "new" filename with an empty file and not crash nickel? Or does it need to be a minimal stub?

[pgaskin]

Okay, here's a crazier idea: binary patch a flag during the failsafe restore (say, a global bool or something) to flip it from false to true and use it to check if this iteration of the library has already been initialized (i.e., patched) once...

That's a possibility. I can easily append data to the end of a binary and read that if needed.

Or, mildly less crazy, restore the lib with a different filename in the failsafe and use the lib's name as an indication that it's a fresh install?

That might be an idea. My main concern is that it's already annoying enough dealing with two libs, when it tries to load both.

EDIT: But then how do you deal with updates? Can we clobber the "new" filename with an empty file and not crash nickel? Or does it need to be a minimal stub?

Updates would have to be a two step process ... unless ... I detected the new one, and dlopened its init instead.

And yes, empty files won't crash nickel. Before Qt opens plugins, it parses their ELF header manually to ensure it has the qt plugin metadata section, then reads that to ensure compatibility. If it fails the check, it doesn't even get dlopened.

[pgaskin]

I just had another idea. What if I made it so if the config dir doesn't exist, an Uninstall NickelMenu option is added to the menu too.

[shermp]

I just had another idea. What if I made it so if the config dir doesn't exist, an Uninstall NickelMenu option is added to the menu too.

Sounds like a simple, sane, and explicit solution to me. I like it.

[pgaskin]

@NiLuJe which idea do you want (this is mainly for the OCP packages)?

[NiLuJe]

@geek1011: Whichever you prefer and/or is the least of a maintenance burden, I'm personally fine with both ;).

[pgaskin]

I think I'll just go with the build flag option for now, as it is slightly easier to use from a user's perspective, and fits better with the OCP packages. I might eventually make this the main method of uninstallation, but I haven't decided on that yet.