usbromservice binary/source install odd behaviour

[movisman]

Hi there,

Just noticed something which might be a bug, but is minor.

On a fresh install of the image, usbromservice is installed by default, and when you check it out in RetroPie-Setup, it is labelled as 'installed from source'.

On my existing instance, usbromservice was never installed. This was originally deployed from a buster build from mid Jan so that could be for a number of reasons. Anyway, I decided to install it as I might play around with the functionality - however the only option was to 'install from pre-compiled binary' - no problem there... although the option presented is different to how it is pre-installed on the image (installed via source).

It installs fine, but after install I notice two things:

A) The source folder /tmp/build still has files and folders in it regarding usbromservice, and the option 'Z Clean source folder' is available. Selecting this of course cleans up the stuff in the /tmp/build directory but I assume this should be done automatically?

B) After installing via binary, unlike other packages which are able to verify if the binary is up to date or not - this one says 'Binary update may be available (Unable to check for this package).

And as previously mentioned, I cannot install from source to match what the pre-built image does, as there is no option for that.

To note, on the fresh image with updated RetroPie-Setup script, initially there is an option to update via source. However, if you uninstall the script, the option to install via source goes away. You can then only install via pre-compiled binary. By doing this, you then encounter the same issues as I outline in point A) and B) above, so it is very easy to replicate on a fresh install.

None of this is a big deal, but perhaps it is something to consider looking at for housekeeping reasons?! Just found it a bit strange that's all and it doesn't quite work like the other packages.

Thanks!

PS. Can provide screenshots if need be.

[mitu]

@movisman said in usbromservice binary/source install odd behaviour:

On a fresh install of the image, usbromservice is installed by default, and when you check it out in RetroPie-Setup, it is labelled as 'installed from source'.

Are you sure ? Do you have the latest RetroPie-Setup version installed ?

On my existing instance, usbromservice was never installed. This was originally deployed from a buster build from mid Jan so that could be for a number of reasons. Anyway, I decided to install it as I might play around with the functionality - however the only option was to 'install from pre-compiled binary' - no problem there... although the option presented is different to how it is pre-installed on the image (installed via source).

Manual installation will not install the package - it's installed explicitely on the Pi images.
But, about the installation from source - are you looking at the same platform (Pi) when comparing the available options ?

It installs fine, but after install I notice two things:
A) The source folder /tmp/build still has files and folders in it regarding usbromservice, and the option 'Z Clean source folder' is available. Selecting this of course cleans up the stuff in the /tmp/build directory but I assume this should be done automatically?

Yes, that's an oversight, should be fixed.

B) After installing via binary, unlike other packages which are able to verify if the binary is up to date or not - this one says 'Binary update may be available (Unable to check for this package).

There are other modules that are binary only, but they're not packaged since there's no point in doing so (i.e. ports that install through .deb files or 3rd party emulatorts which supply binaries). It's normal.

[movisman]

@mitu - thanks for the reply.

To answer your questions:

Are you sure ? Do you have the latest RetroPie-Setup version installed ?

Yep, absolutely. I downloaded the standard image from the site, deployed it, checked and it says 'installed from source'. I then updated the setup script and it stays the same.

Manual installation will not install the package - it's installed explicitely on the Pi images.
But, about the installation from source - are you looking at the same platform (Pi) when comparing the available options ?

Yep, same platform (my Picade), Rpi 3. The buster image I used on this was from back in Jan and was from the weekly builds, so it was an image (not manual). I have two SD cards - one which is 'production' (which has been subsequently updated) originally deployed back in Jan with a buster weekly image - and another SD with a brand new image which I put on there yesterday to test. So am using exactly the same hardware and setup. In theory, the buster image back from Jan should have installed usbromservice as it wasn't a manual install. It also had the source files in the tmp/build folder, but the script was suggesting it wasn't installed. Perhaps I removed it but I don't think so. This isn't an issue though, as we are only really fussed with how the 'current' image behaves.

To replicate the source install thing, all I need to do is deploy a fresh image (current is April 28, 2020, Pi 2/3 variant) and that's it (updating script post install doesn't change anything). You can then see in the package manager that usbromservice appears to be 'installed from source'. You can also click 'update from source' and it'll update. However, as I mentioned above, if you remove it, the install from source option goes away, and you can then only install via pre-compiled binary, which I assume is what it should be displaying in the first place.

Yes, that's an oversight, should be fixed.

Great, no worries!

There are other modules that are binary only, but they're not packaged since there's no point in doing so (i.e. ports that install through .deb files or 3rd party emulatorts which supply binaries). It's normal.

I see. Currently my picade is only running the main/core packages, nothing 3rd party nor any ports. I only mention because none of the other binary packages installed on the system display like this, they all say 'you are running the latest binary'. This one is the only exception in terms of showing the message 'Binary update may be available (Unable to check for this package)'. So I wanted to ask, just in case that was another bug of sorts.