When development stops for a router model, does its repository eventually get pulled down?

[manywrt]

My router is a TP-Link C7 v5 running on an OpenWrt release 19.07.8 custom image.

I understand that the development has ended for this model and that version 19.x.x is the latest, as it were.

QUESTION:

Will I one day try to make a new image with something like:

make image PROFILE=tplink_archer-c7-v5 PACKAGES="[package names]" FILES=files/

and find that the repository is gone as a matter of policy?

"Policy" here means folks maintaining OpenWrt deciding that nobody should be compiling a 19.x.x image, i.e. that I should get a new router.

[slh]

@manywrt

My router is a TP-Link C7 v5 running on an OpenWrt release 19.07.8 custom image.

I understand that the development has ended for this model and that version 19.x.x is the latest, as it were.

Incorrect, the archer c7-v5 is still fully supported in 23.05.3 and main snapshots, there's no reason for it to drop out of support anytime soon.

[manywrt]

@slh

still fully supported in 23.05.3

That's at once a great news and potentially a distressing one.

Great because obviously I have a chance to update myself. By the way anybody else with the same machine go here for main snapshots: https://openwrt.org/toh/tp-link/archer_c7

Distressing because I made my latest image in October 2021 and got myself a 19.07.8.

Does it mean that I was a fool and went out of my way somehow to get an outdated version?

Ah, I remember I was running Ubuntu 18.04 in 2021 (from sheer laziness). Maybe Ubuntu 18.04 could not update its OpenWrt packages and could only give me an older image. Could that happen?

Or could it be that there was no update between 2019 and 2021 and so 2019 was the latest as of 2021? This would be incredible.

ADDED LATER:

If anybody is curious, I got an image version 19.x.x in 2021 because I specifically went and got the outdated version of imagebuilder from a then outdated page. I was just being clueless.

[slh]

The c7-v5 was supported in every intermediate release, it never fell out of support.

The host OS is unrelated to that (to a large extent, at least), but you do need the current imagebuilder or update your source checkout, whatever you chose to do. Given that you are fairly out of date, you really should make a completely fresh start.

[manywrt]

@slh

you really should make a completely fresh start

Thanks. I'll do.

I have a Debian and a Manjaro machine. Would it (custom image building) go smoother on one or the other?

Looking at https://openwrt.org/docs/guide-developer/toolchain/install-buildsystem, it would appear the package install phase is somewhat simpler for Debian. (Sorry about this extreme newbie nature of the questions. I don't have a background in computing and am always learning just enough for what I need to do.)

[slh]

Anything rermotely recent goes, Debian is well tested though.

[Ramon]

Why not use a prebuild image or use the firmware selector https://firmware-selector.openwrt.org/?

[Falco]

I was about to ask the same, you can also add needed packages there to include in your specific build.

[manywrt]

@Ramon

Why not use a prebuild image

It's been a while, and I had to try and recall the reasons.

• Packages: Putting them all into a custom image resulted in a smaller install than starting with a prebuilt and separately installing the same packages.
• Configurations: Putting them into a custom image meant that, when the router blew up in my face, I could just re-flash and be done (unless there were subsequent tweaks, which would have to upload manually or from a backup).

@Falco

you can also add needed packages there to include in your specific build

Looks to me the selector would take care of the first bullet ("Packages") just as nicely.

[diogohvo]

@manywrt

Packages: Putting them all into a custom image resulted in a smaller install than starting with a prebuilt and separately installing the same packages.

When using the firmware selector, you can add packages to be included in that image, as mentioned by the other replies.

@manywrt

Configurations: Putting them into a custom image meant that, when the router blew up in my face, I could just re-flash and be done

The firmware selector also has you covered in this aspect, since it allows you to setup a uci-defaults script, meaning you can reflash your device and those configs will remain.

Although depending on the complexity of your configs, a script may not be ideal, and then a custom image with custom files may be easier if you already have a build environment

[Ramon]

@manywrt

• Packages: Putting them all into a custom image resulted in a smaller install than starting with a prebuilt and separately installing the same packages.
• Configurations: Putting them into a custom image meant that, when the router blew up in my face, I could just re-flash and be done (unless there were subsequent tweaks, which would have to upload manually or from a backup).

The 1st argument might be relevant if you actually run out of space, otherwise kinda irrelevant.
The 2nd argument actually can blow up in your face even more. If the config does not work on the new version for whatever reason then you may need to resort to TFTP or soldering or whatever. I like it that I can reset my router and know I end up with a workable state where I can then start with reconfiguring/uploading the backup files.

But in the end its up to you of course

[manywrt]

@Ramon

The 2nd argument actually can blow up in your face even more. If the config does not work on the new version for whatever reason then you may need to resort to TFTP or soldering or whatever. I like it that I can reset my router and know I end up with a workable state where I can then start with reconfiguring/uploading the backup files.

That's cogent.

I believe I can come up with a composite approach. Which may go: 1. Bake into initial image of a new version OpenWrt only the openssh related configs (and keys), which I might safely presume will remain stable in the way they work. (I installed openssh in addition to dropbear just so I could have consistency across all my machines or so I don't have to find out e.g. what is the authorized_keys equivalent of dropbear.) 2. Upload other configs. 3. After confirm they work for the new version OpenWrt, create custom image (including configs) for any intra-version blowups.

I realize that even step 1 involves using the imagebuilder (unless I figure out a way to use a uci-defaults script to write an SSH key), but I am providing against an old config bricking a new version image.