Installing specific package versions?

Hello fellow OpenWrt enthusiasts! I'm struggling with an issue while trying to creating an image restoration script and wondering where I'm going wrong at...

I'm just trying to tell 'opkg' to install a specific version, which it seems to support.

If several versions of a package are available in a repo, opkg defaults to the latest one. To force opkg to use a different version, the syntax = is used. For example, in a repo that has version 1.0, 2.0 and 3.0 of 'a', the following command will install version 1.0:

opkg install a=1.0

The syntax is the same used by apt-get.

So I was trialing this method with an arbitrary package I didn't care too much about, but had little success:

opkg install youtube-dl=2016.11.27-1

Which results in:

root@LEDE:~# opkg install youtube-dl=2016.11.27-1
Unknown package 'youtube-dl=2016.11.27-1'.
Collected errors:
opkg_install_cmd: Cannot install package youtube-dl=2016.11.27-1.

Am I missing something here, or is this not supported? I've tried a few variations of this but nothing seems 'to stick'. Any help would be appreciated :slight_smile:

I think the openwrt version forked before that point, and doesn't support it anyway.

Is there some way to tell the fork date / version? The standard command isn't very useful...

root@LEDE:~# opkg --version
opkg version 1d0263bb40e3c099501fc1f2431907636230e7f2 (2017-03-23)

This specific package version thing feels like a thing that should be supported...

I think, checking the source is the fastest way to verify if that feature is still supported:

The package system in OpenWrt should only be considered to support the packages that were compiled in conjunction with the installed ROM. It is not apt or the like, where you can potentially mix and match.

See the multiple, recent threads around "upgrading" OpenWrt by bulk-install of packages for many of the reasons why this doesn't work reliably, as well as causing flash-utilization problems.

Thanks for the insight Jeff. I guess for my use case, I just want a reproducible 17 image, but not sure what all has been added / upgraded since the base.. At a minimum the image has an OpenVPN configured, DDnS, and a few other items.

Is there any other better way to create a reproducible LEDE 17 image other than 'freezing' the current config / package list, and using this along with the configs for a new build?

Restored configs on the new hardware don't have the other opkg tidbits added so.. it's only partially restored.

You can capture the state of the various "feeds" repos as they update quite often. They are git repos, but are shallow clones, by the default behavior of ./scripts/feeds. They can be "deepened" through either

git fetch --depth <some number>
git fetch --unshallow

depending on how much history you need or want.

Likely not supported...

It is not obvious, but we are using an ancient year 2011 version of opkg, slightly modified, but still an ancient version.
You new feature was apparently introduced in 0.3.2 in about year 2016, much later than our version...

https://github.com/openwrt/openwrt/commit/b65dc04712dfb8cc7bb9036c7c73b0cead6dd7c9#diff-36475733f5e031004d3fbab01a3c3ddd

See the year gap here (2011-2017):
https://git.openwrt.org/?p=project/opkg-lede.git;a=shortlog;pg=1

Dang :frowning:

Is the solution then to take a step back, install the build tooling, and author an independent .img / .bin for this specific configuration?

I'm coming from the reverse-engineer angle where I don't really know what all is there... Is there some way to dump this info from an in-use image for the build chain?

Sorry if these are all dumb questions - somewhat new to this. Also found other backup options but unsure about their usability in this case.

Easy:

As long as you are willing to compile it yourself, it is easily reproducible.

1 Like

Depends on the build.
I include in my personal images the exact source versions of all feeds with this style embedded in the final image:

OpenWrt master r9497-6b2874707a / 2019-03-02 11:19
---
main      2019-03-01 6b28747 oxnas: switch to DTS aliases for LEDs and
luci      2019-03-02 958e830 Merge pull request #2606 from castillofra
packages  2019-03-01 fa86d38 Merge pull request #8318 from Andy2244/so
routing   2019-02-22 34e4913 Merge pull request #448 from SvenRoederer

But this info is not embedded by default into any image.

My personal take on things:

  • Image builder -- assembles images from pre-compiled sources; targeted at end users for occasional use
  • SDK -- not sure why this exists; perhaps for people with limited bandwidth or compute power?
  • Build chain -- builds from source; targeted at advanced users (doesn't require much more prereqs than the image builder)

Like @hnyman, I capture details of everything in my builds with a set of personal scripts, so I can know just what was in that image that worked or failed, along with tarball of all untracked files in my build system. Serious overkill for most people; capturing the git commits of the various repos and your config/files directory is sufficient if you're only working with upstream branches.

Thanks for the input @hnyman and @jeff. I wrote a small .py to take a look at the diff between this LEDE 17 build (opkg list, diff the list) and found the build to be a bit egregiously bloated...

Going to take a look into the image build chain get a better handle on managing needed packages :slight_smile: