Usability suggestion: Installed Packages customization makes it easy to create a brick-able build

[itsthejb]

Hi everyone,

First of all, thanks for the great work on this project and everything associated! I recently tried out some more advanced functionality (firmware selector customized builds), and managed to shoot myself in the foot rather easily. However, it seems like this could be inspiration for a user-friendliness improvement?

• The customized build Installed Packages functionality allows adding additional packages to the image
• However, the way this is implemented in the web interface makes it very easy to accidentally create a build that is missing critical packages

Steps

• Attempt to paste a complete set of desired packages into the text field
• Make some error, resulting in leaving out a critical package (for example procd)
• Request Build
• Flash image

Expected behaviour

• Either it is not possible to remove critical packages, or some warning is emitted

Actual behaviour

• Build validation is performed; however this does not do anything to protect against missed critical packages. The uninformed user may falsely assume that this validation provides some kind of protection of this kind

Suggested improvements

It seems this problem could be fixed in a simply (adjusting the UI) or more deeply (build validation). Probably it's enough to just adjust the UI:

• Split Installed Packages into two boxes: one which is Essential Packages which is pre-filled with the contents for each device as now. Then have another Extra/User Packages which starts out empty. Here the user can add their desired packages and reduce the risk of accidentally changing the essential packages. Added packages then becomes the union of these two sets of packages
• As an additional layer of protection, how about something like requiring a checkbox to enable the Essential Packages field?

Overall I understand that this is advanced functionality. However, mistakes can happen and it seems like this can protected against with some minor changes. I would create a patch myself, but I'm afraid web dev is not my speciality 🙃

Thanks in advance!

Related forum post: https://forum.openwrt.org/t/solved-bricked-fritz-box-7530-customized-sysupgrade-missing-critical-packages/211748

[mwarning]

Nice write up. But @aparcar has to decide on this.
We could also add the device packages by default in the background or juts make them non-removeable.

[mwarning]

@aparcar doesn't mind on how this is improved.
@itsthejb the device_packages seem to also contain a bunch of optional packages that are definitely not essential. Like ppp* or opkg. So it is impossible to determine if a package is essential...

[itsthejb]

Hey @mwarning,

Well it doesn't have to be bullet-proof; it could be as simple as just having the two input fields, one pre-filled with the "standard packages", and another empty one to add "additional packages". I imagine that most of the time people will only want to add packages to the second box, and for those that want to touch the standard packages, that's also available

That would be the MVP to increase the difficulty to accidentally removing a critical package

[mwarning]

With two package boxes called "standard packages" and "additional packages" people will ask into what window packages need to be added.
A better solution would be nice.

[mwarning]

A quick but very minor improvement would be to put the device packages at the start of the list.

[itsthejb]

Then I still like the idea of having the two boxes whereby the "standard packages" (or whatever it is labelled) is disabled by default and requires ticking a checkbox to enable that has a warning along the lines of "removing packages from this section can risk a non bootable build. Please take care" etc. alternatively it is under a further disclosure indicator with a similar warning

Regarding ordering the packages in a single box, the danger here is copy and pasting a complete set which still misses a critical package. This is similar to what happened to me. It's a very minor change, I agree, but I think the amount of extra protection is also very minimal

[mwarning]

Here is a MR that would introduce two input boxes: #49

[mwarning]

It looks like the preferred way would be to show a warning message if a default package is missing.
Now it needs to be implemented.