dpkg-offline Local repository is lower-priority than remotes in sources.list
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
dpkg-offline |
Fix Released
|
High
|
Daniel Manrique |
Bug Description
A test system with 12.04.4 server was installed on a Virtualbox VM, choosing only openssh server in the task selection. Once the install is completed, a dpkg-offline-
add-ofline-
When apt-get installing checkbox -certification-
Failed to fetch http://
Failed to fetch http://
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Interestingly, most of these packages are provided in the tarball.
One other instance also reported these failures to download, *but* was able to install checkbox-
apt-cache policy reports the remote repo has priority:
$ apt-cache policy stress
stress:
Installed: 1.0.1-1build1
Candidate: 1.0.1-1build1
Version table:
*** 1.0.1-1build1 0
500 http://
500 file:/var/
100 /var/lib/
Some research indicates it's not possible for a repository placed in a different apt.list.d file to have higher priority if it provides the *same* package and version as one appearing before it:
http://
Thus there's no clever way to bump our priority to make the local package install prioritarily.
Two options are left:
1- Instead of using an apt.list.d file, add our dpkg lines directly at the *top* of /etc/apt/
2- the apt-add-repository script should comment out all repositories in /etc/apt/
Option 2 seems simpler, since it will use just sed to comment out lines. Option 1 would involve more complicated parsing of sources.list, which further complicates our uninstall process (which currently just deletes a file).
In the meanwhile, the suggested workaround is to manually comment all entries in sources.list, before installing the tarball. For the dpkg_offline use case this should be OK, since the system is most likely offline.
Still, for use on systems with some sort of connectivity, we should allow control over which sources.list entries are munged.
Related branches
Changed in dpkg-offline: | |
importance: | Undecided → High |
status: | New → Confirmed |
Changed in dpkg-offline: | |
status: | In Progress → Fix Committed |
Changed in dpkg-offline: | |
status: | Fix Committed → Fix Released |
Yech :( So I did the work to ensure our local repo has priority:
$ apt-cache policy freepats local-apt- repositories/ apt-repo- trusty- desktop- amd64.iso- 20140210- git_13a1. 9rc1-1_ amd64_stress_ 1.0.1-1ubuntu1_ amd64_openttd_ 1.3.3-1build1_ amd64/ ./ Packages archive. ubuntu. com/ubuntu/ trusty/universe amd64 Packages
freepats:
Installed: (none)
Candidate: 20060219-1
Version table:
20060219-1 0
500 file:/var/
500 http://
The package is available from the local repo first, then the remote one. Still, by disabling connectivity through specifying an invalid proxy, it still insists on trying to download the remote packages:
$ sudo apt-get install freepats archive. ubuntu. com/ubuntu/ trusty/universe freepats all 20060219-1 archive. ubuntu. com/ubuntu/ pool/universe/ f/freepats/ freepats_ 20060219- 1_all.deb Could not connect to 10.153.104.60:1328 (10.153.104.60). - connect (111: Connection refused)
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
freepats
0 upgraded, 1 newly installed, 0 to remove and 21 not upgraded.
Need to get 29.0 MB of archives.
After this operation, 34.0 MB of additional disk space will be used.
Err http://
Could not connect to badproxy:1328 (badproxy). - connect (111: Connection refused)
E: Failed to fetch http://
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?
Looks like we will have to resort to disabling all existing repositories :(